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

Reply via email to