I don't think we need to override to_xml if are diligent about the schema.
James Kebinger wrote: > I'm not sure we need the type information, it serves to bloat the xml. > Do we need to override the xml for now if we ensure the correct schema > is used? > > > On 3/6/07, * Luke Melia* <[EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]>> wrote: > > From > http://api.rubyonrails.org/classes/ActiveRecord/XmlSerialization.html > > "To not have the column type included in the XML output, set > :skip_types > to false." > > Before we override to_xml, maybe we should ask: do we want to include > types in our output XML at all? I don't think it's necessary. Other > thoughts? > > Luke > > Luke Melia wrote: > > 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] > <mailto:[EMAIL PROTECTED]> > >> <mailto:[EMAIL PROTECTED] <mailto:[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] > <mailto:[EMAIL PROTECTED]> > >> <mailto: [EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]>>> wrote: > >> > >> On Fri Mar 02 14:32:46 UTC 2007, James Kebinger > >> < [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> > <mailto:[EMAIL PROTECTED] <mailto:[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 <http://www.rousette.org.uk> > >> [EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]> > <mailto:[EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]>> > >> > >> > >> > >> <schemadiff.txt> > > > > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > Tracks-discuss mailing list > > [email protected] > <mailto:[email protected]> > > http://lists.rousette.org.uk/mailman/listinfo/tracks-discuss > <http://lists.rousette.org.uk/mailman/listinfo/tracks-discuss> > > _______________________________________________ Tracks-discuss mailing list [email protected] http://lists.rousette.org.uk/mailman/listinfo/tracks-discuss
