It appears to me that the underlying issue is that running using a database
loaded using rake db:schema:load is not a valid configuration due to the
information lost by round tripping the schema through the database - in this
case its mysql losing the boolean attribute information but I'm sure that
the true "intention" of the original schema would probably distorted by a
trip through any database. The tests should be written to run against a
database built by running rake db:migrate.
(I originally couldn't get db:migrate to work until installing a newer
sqllite and/or using the sqlite that came with locomotive's jan 2007
package)
A less desirable alternative is to override to_xml and do our own xml
serialization so that it is always in some canonical format.
I was poking through the active record docs, and although one can override
the getters and setters for model attributes, doing so doesn't change how
to_xml works. I also noticed that the model automagically defines a "hide?"
method that returns a boolean under any configuration, which is why the
system works either way, except in the case of xml serialization.
Any thoughts on either of these approaches (deprecating db:schema:load vs
overriding to_xml)  or another approach so that the tests work all of the
time?


On 3/4/07, bsag <[EMAIL PROTECTED]> wrote:

On Fri Mar 02 14:32:46 UTC 2007, James Kebinger <[EMAIL PROTECTED]>
wrote:
> That is an interesting point Fred that I did not think of. If it is the
case
> that the xml api output differs between database types, then that would
seem
> to be an important problem to solve, because the model's "hidden"
attribute
> is boolean and it should look that way to the outside world, regardless
of
> how the database represents it.

That's obviously where the test error comes from: I get the same error
using MySQL as my test db, and the output clearly encodes hide as a boolean
rather than an integer as it does on SQLite3.

However, this - if I understand it correctly - is a 'feature' of Rails,
rather than a result of how it is coded in Tracks. I suspect that the Rails
to_xml() method uses the same ActiveRecord functions to translate entities
between the different database types that are used in the rest of the stack,
and that (for some reason) converts a :boolean to an :integer when it's
making a SQLite3 db. If you look at db/migrate/001_create_tracks_db.rb, you
can see that the hide column is set as :boolean.

Preserving the format of the field as the database specific type probably
has its advantages if you want to import data back, but I can see that it
makes writing API scripts a bit more complicated.

cheers,

bsag

--
but she's a girl - the weblog of a female geek
http://www.rousette.org.uk
[EMAIL PROTECTED]

_______________________________________________
Tracks-discuss mailing list
[email protected]
http://lists.rousette.org.uk/mailman/listinfo/tracks-discuss

Reply via email to