Skip to Content.
Sympa Menu

comanage-dev - Re: [comanage-dev] fix for extended attribute form and MySQL

Subject: COmanage Developers List

List archive

Re: [comanage-dev] fix for extended attribute form and MySQL


Chronological Thread 
  • From: Scott Koranda <>
  • To: Benn Oshrin <>
  • Cc:
  • Subject: Re: [comanage-dev] fix for extended attribute form and MySQL
  • Date: Wed, 28 Sep 2011 10:30:17 -0500

Hi,

> It seems like you're done replying to yourself, so I'll chime in now :)

Oh, you could have chimed in at anytime... ;-)

>
> Ultimately, I'd like to get rid of adodb/axmls, but the schema
> management in Cake 1.3 is pretty bad, so we'll probably need to keep
> it around for a while. However, that does support your approach of
> modifying the thing we're going to get rid of.
>
> Since we don't have data points beyond Postgres and MySQL, it's
> unclear whether the common case is it works (ie: Postgres) or it
> breaks (ie: MySQL), so it's not obvious which way the patch should
> work. That said, I'd be inclined to go with your "patch for MySQL"
> approach, since Postgres "just works".

Ok, I have code ready to go then and will send it around
before committing since this is my first go around with you...

>
> We'll need to document your changes by linking to JIRA from
> database.php (assuming you mean app/vendors/shells/database.php).

Yes.

So you want a comment in app/vendors/shells/database.php that
includes a URL to the Jira issue?

> I'm sure you've already put in a descriptive comment :)

Yes, but I can add a URL to the Jira.

On another note, I am going to work through a cakePHP
tutorial, but after that I would like some guidance on which
Jira issue to attack next...

Thanks,

Scott

>
> On 9/27/11 3:00 PM, Scott Koranda wrote:
> >>>>>I don't think we can get away with that since we have booleans in
> >>>>>other contexts and we'll need a general fix. (And the fix could end
> >>>>>up being that we need to roll back the migration to ADODB/AXMLS.)
> >>>>>
> >>>>>This issue could be how ADODB represents a boolean in MySQL vs how
> >>>>>Cake does it. We should figure that out and then bang our heads
> >>>>>against the wall.
> >>>>
> >>>>Cake appears to only automagically conjure up a checkbox when
> >>>>the column type is boolean or a tinyint with length 1:
> >>>>
> >>>>http://book.cakephp.org/view/189/Automagic-Form-Elements
> >>>>
> >>>>ADODB/AXMSL is casting
> >>>>
> >>>><field name="indx" type="L" />
> >>>>
> >>>>without a size option to tinyint(4) for MySQL and cake is not going to
> >>>>automagically conjure up a checkbox.
> >>>>
> >>>>Adding a size option causes ADODB/AXMLS when run via 'cake
> >>>>database' to fail to provision the co_extended_attributes
> >>>>table for PostgreSQL (it works fine for MySQL).
> >>>>
> >>>>The actual functioning during database calls with tinyint(4)
> >>>>in MySQL is not affected (it happily stores a 0 or 1).
> >>>>
> >>>>Would you prefer to
> >>>>
> >>>>- stop relying on the automagic and coerce all boolean types
> >>>> for forms when necessary
> >>>>
> >>>>- rely on the automagic and hack ADODB/AXMLS
> >>>
> >>>So I see in app/vendor/shells/database.php how to hook into
> >>>ADOdb.
> >>>
> >>>It looks like the adoSchema object supports a method called
> >>>'TransformSchema' that supports pointing to a file containing
> >>>or directly including an XSL string to massage the schema.
> >
> >Unfortunately 'TransformSchema' is really a special method for
> >internal use and cannot be easily used to load some generic
> >XSL and do the transform.
> >
> >But it was straightforward to do it directly inside of an
> >if/else clause in main() in database.php using an instance of
> >XSLTProcessor.
> >
> >The XSL needed to add the attribute 'size="1"' to<field/>
> >elements with 'type="L"' is just a few lines and can be put
> >right next to the schema in app/config/schema.
> >
> >I tested this and it works. I just need to clean up the code a
> >bit.
> >
> >Shall we do it this way? It seems generic enough since it will
> >force all booleans to be represented by TINYINT(1) in MySQL
> >and hence preserves the cakePHP automagic.
> >
> >Let me know...
> >
> >Scott
> >
> >>>
> >>>We could modify the schema and set
> >>>
> >>><field name="indx" type="L" size="1" />
> >>>
> >>>so that MySQL would get TINYINT(1) and PostgreSQL would break.
> >>>
> >>>But in database.php we could add a check and if the database
> >>>being used is PostgreSQL then we could call TransformSchema()
> >>>with appropriate XSL to remove the 'size="1"' option for the
> >>>field, thus not breaking PostgreSQL.
> >>
> >>Or better yet probably, leave the schema the way it is and
> >>detect that MySQL is being used and add size="1" to all fields
> >>of type="L"...
> >>
> >>>
> >>>How does that sound? Should I take the time to give it a go?
> >>>
> >>>Scott
> >>>
> >>>>
> >>>>- revert ADODB/AXMLS
> >>>>
> >>>>?
> >>>>
> >>>>Thanks,
> >>>>
> >>>>Scott
> >>>>
> >>>>>
> >>>>>On 9/27/11 10:52 AM, Scott Koranda wrote:
> >>>>>>Hi,
> >>>>>>
> >>>>>>See https://bugs.internet2.edu/jira/browse/CO-175
> >>>>>>
> >>>>>>I tried to massage the schema but PostgreSQL didn't like it so
> >>>>>>instead I coerced the form to display a checkbox even if MySQL
> >>>>>>has tinyint(4) for the data type of the 'indx' column.
> >>>>>>
> >>>>>>Can I commit the code?
> >>>>>>
> >>>>>>Thanks,
> >>>>>>
> >>>>>>Scott
> >>>>>
>



Archive powered by MHonArc 2.6.16.

Top of Page