comanage-dev - Re: [comanage-dev] fix for extended attribute form and MySQL
Subject: COmanage Developers List
List archive
- From: Scott Koranda <>
- To: Benn Oshrin <>
- Cc:
- Subject: Re: [comanage-dev] fix for extended attribute form and MySQL
- Date: Tue, 27 Sep 2011 14:55:11 -0500
> > 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.
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.
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
> >
- [comanage-dev] fix for extended attribute form and MySQL, Scott Koranda, 09/27/2011
- Re: [comanage-dev] fix for extended attribute form and MySQL, Benn Oshrin, 09/27/2011
- Re: [comanage-dev] fix for extended attribute form and MySQL, Scott Koranda, 09/27/2011
- Re: [comanage-dev] fix for extended attribute form and MySQL, Scott Koranda, 09/27/2011
- Re: [comanage-dev] fix for extended attribute form and MySQL, Scott Koranda, 09/27/2011
- Re: [comanage-dev] fix for extended attribute form and MySQL, Scott Koranda, 09/27/2011
- Re: [comanage-dev] fix for extended attribute form and MySQL, Benn Oshrin, 09/28/2011
- Re: [comanage-dev] fix for extended attribute form and MySQL, Scott Koranda, 09/28/2011
- Re: [comanage-dev] fix for extended attribute form and MySQL, Scott Koranda, 09/28/2011
- Re: [comanage-dev] fix for extended attribute form and MySQL, Benn Oshrin, 09/28/2011
- Re: [comanage-dev] fix for extended attribute form and MySQL, Benn Oshrin, 09/28/2011
- Re: [comanage-dev] fix for extended attribute form and MySQL, Scott Koranda, 09/27/2011
- Re: [comanage-dev] fix for extended attribute form and MySQL, Scott Koranda, 09/27/2011
- Re: [comanage-dev] fix for extended attribute form and MySQL, Scott Koranda, 09/27/2011
- Re: [comanage-dev] fix for extended attribute form and MySQL, Scott Koranda, 09/27/2011
- Re: [comanage-dev] fix for extended attribute form and MySQL, Benn Oshrin, 09/27/2011
Archive powered by MHonArc 2.6.16.