Sorry, I actually messed up that example - I had inserted some 'puts' into the code to see what was going on and one of them was foolishly placed at the end of the method and prevented the return value coming back (doh!).
BUT... further investigation does seem to confirm that there is indeed a problem, and it does occur with the 'Event' model I posted before. What I've found is that if there is a 'Text' property in the model and an instance of the model is loaded but with that property not loaded due to lazy loading, if I then explicitly assign to the property the same value it already has, attempting to save it will return false. e.g. ----- $bin/merb -i irb(main):001:0>e = Event.new(:name => 'test') => #<Event @id=nil @name='test'> irb(main):002:0> e.save => true irb(main):003:0>e = Event.get(1) => #<Event @id=1 @name=<not loaded>> irb(main):004:0> e.name = 'test' => "test" irb(main):005:0> e.save => false irb(main):006:0> e => #<Event @id=1 @name="test"> ----- The problem only seems to happen with Text properties. Also if I have multiple lazily-loaded Text properties and assign to any one of them a value that's different from its existing value, the save will return true. Setting :lazy => true on the Text properties overcomes the immediate problem, but that is obviously not a preferred solution in general. This appears to be a bug. Unless someone suggests there's something obvious I'm missing - which is completely possible, I'll file a ticket on lighthouse. Mark. On Oct 21, 9:38 am, MarkMT <mark.thom...@ieee.org> wrote: > Ok, I've been trying to isolate the simplest example that causes > problems. Here's a model - > > ------ > class Event > include DataMapper::Resource > > property :id, Serial > property :name, Text > end > ------ > > And an irb session - > > ------ > $bin/merb -i > irb(main):001:0>e = Event.new > => #<Event @id=nil @name=nil> > irb(main):002:0> e.save > => true > irb(main):003:0>e = Event.get(1) > => #<Event @id=1 @name=<not loaded>> > irb(main):004:0> e.name = 'test' > => "test" > irb(main):005:0> e.save > => false > irb(main):006:0> e > => #<Event @id=1 @name="test"> > -------- > > So what seems to happen is that 'save' returns false, even though the > object is saved successfully. I've tried the same thing with the :name > attribute defined as a String and get the same result except that the > nil name gets loaded when Event.get(1) is executed. > > I would be interested to know if someone can reproduce this or suggest > what is going wrong. > > Mark. > > Kai Chen wrote: > > I think giving a code snippet to reproduce the problem will be helpful. > > > -- > > Regards, > > Kai Chen > > > On Tue, Oct 20, 2009 at 9:40 AM, MarkMT <mark.thom...@ieee.org> wrote: > > > > Hmm... not sure, but seems like that method is maybe defined by a call > > > to rb_define_method in do_mysql_ext.c, though I don't claim to really > > > understand what is going on there. So I'm left wondering how to figure > > > out why the resource's update method returns false. > > > > Clues appreciated. FWIW, I'm trying to debug something that works fine > > > in DM 0.9.11 with Merb 1.0.11. > > > > Mark. > > > > MarkMT wrote: > > >> I'm trying to track down a problem I have with a resource in 0.10.1 > > >> that is failing to be saved despite passing its validations. > > > >> Updating the resource leads to the invocation of > > >> DataMapper::Repository#update, which is defined in dm-core/ > > >> repository.rb. This method calls 'update' on a > > >> DataMapper::Adapters::MysqlAdapter object, which is subclassed in dm- > > >> core/adapters/mysql_adapter.rb from > > >> DataMapper::Adapters::DataObjectsAdapter. > > > >> That class is defined in dm-core/adapters/data_objects_adapter.rb and > > >> and its 'update' method calls 'execute' which creates a > > >> DataObjects::Mysql::Command object and calls 'execute_non_query' on > > >> it. > > > >> However, I'm having difficulty figuring out where that class and its > > >> 'execute_non_query method' is defined. grep only turns up > > >> DataObjects::Command#execute_non_query, but that isn't what is being > > >> called. > > > >> Can someone point me in the right direction? --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "DataMapper" group. To post to this group, send email to datamapper@googlegroups.com To unsubscribe from this group, send email to datamapper+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/datamapper?hl=en -~----------~----~----~----~------~----~------~--~---
