It looks like I checked in the last change. I've noticed that this
file changes a lot, often when no changes were made to the schema.
If making sure it gets generated with the :boolean type info solves
this issue, I can be diligent about that (maybe even write a test for
it!).
Thanks for digging into this!
Luke
On Mar 4, 2007, at 10:18 PM, James Kebinger wrote:
Apologies for replying to myself, but I'm just trying to understand
the issue better. It appears that rake db:schema:load would be
perfectly valid to code tests against if the schema.rb file were
different than it is. Does anyone know how the one in SVN got
generated? When I generate it (using MySQL) it has preserved the
boolean type information. (i'll attach the svn diff). There are
quite a few things that are subtly different about the two
generated schemas, but the boolean vs int(4) thing is the biggest.
Snippet from contexts below in case this list doesn't like
attachments:
ActiveRecord::Schema.define(:version => 30) do
create_table "contexts", :force => true do |t|
- t.column "name", :string, :default =>
"", :null => false
- t.column "hide", :integer, :limit => 4, :default =>
0, :null => false
- t.column "position", :integer, :default =>
0, :null => false
- t.column "user_id", :integer, :default =>
0, :null => false
+ t.column "name", :string, :default => "", :null =>
false
+ t.column "position", :integer, :null =>
false
+ t.column "hide", :boolean, :default => false
+ t.column "user_id", :integer, :default => 1
t.column "created_at", :datetime
t.column "updated_at", :datetime
end
On 3/4/07, James Kebinger < [EMAIL PROTECTED]> wrote:
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]
<schemadiff.txt>
_______________________________________________
Tracks-discuss mailing list
[email protected]
http://lists.rousette.org.uk/mailman/listinfo/tracks-discuss
