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]> 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]>> 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]>> wrote: >> >> On Fri Mar 02 14:32:46 UTC 2007, James Kebinger >> <[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 >> [EMAIL PROTECTED] <mailto: [EMAIL PROTECTED]> >> >> >> >> <schemadiff.txt> > > > ------------------------------------------------------------------------ > > _______________________________________________ > Tracks-discuss mailing list > [email protected] > http://lists.rousette.org.uk/mailman/listinfo/tracks-discuss
_______________________________________________ Tracks-discuss mailing list [email protected] http://lists.rousette.org.uk/mailman/listinfo/tracks-discuss
