Em quinta-feira, 19 de abril de 2012 19h01min51s UTC-3, Jeremy Evans escreveu: > > On Thursday, April 19, 2012 2:45:02 PM UTC-7, Rodrigo Rosenfeld Rosas > wrote: >> >> Em quinta-feira, 19 de abril de 2012 15h50min13s UTC-3, Jeremy Evans >> escreveu: >>> >>> On Thursday, April 19, 2012 9:43:49 AM UTC-7, Rodrigo Rosenfeld Rosas >>> wrote: >>> >> I think ActiveModel::Dirty has the same issue, though that could >>> theoretically be fixed as it has access to the initial value. >>> >>> Although not ideal, that is ok. But the issue is that my spec won't >>>> pass. When I try to print "changed_columns" it is empty. Maybe this >>>> information is reset after a save. >>>> >>> >>> changed_columns is cleared during the save. Note that you can access >>> @columns_updated inside the after_update hook to get the data used in the >>> UPDATE statement. >>> >> >> I'm afraid of accessing this internal variable since it is not in the API >> public documentation and so it could change in future versions. Maybe if >> you could document it in the official documentation of Model Hooks, I could >> use it. >> > > This is the officially supported way, announced in the 2.12.0 release > notes. You are right that it should be added to the hooks documentation, > I'll take care of that shortly. >
Great, thanks! I've read somewhere in this group that such feature wasn't requested >>>> before, so I'm requesting it now :P >>>> >>>> Could I ask you to include an official "dirty" plugin for >>>> Sequel::Model? One that would even work in after-hooks? And that would be >>>> completely accurate whatever it means? >>>> >>> >>> I'm not opposed to adding one. It will probably not be exactly like >>> ActiveModel::Dirty, though. I'll probably just give the ability to get the >>> previous value, so you could do: >>> >>> def after_update >>> super >>> options_dataset.delete if type_was_options? >>> end >>> >>> def type_was_options? >>> initial_value(:type) == 'options' && @columns_updated[:type] != >>> 'options' >>> end >>> >>> >> I do like the idea of having access to the initial value of some column. >> That would suffice in my opinion. But I'd write type_was_options? in a more >> compact way though ;) >> >> type != 'options' && initial_value(:type) == 'options' >> > > There's a reason I wrote the the code I did. Your way will probably work > in most cases, but can break in the following code: > > model.type # => 'options' > model.type = 'foo' > model.save(:other_column) # only updates other_column > > Your code would delete the options_dataset even though the type column is > still equal to 'options' in the database. > Okay, I see, but yes, that wouldn't happen in my particular action... > Note that if you have such an option, a better way to do what you want is >>> using a database trigger. >>> >> >> I do have this option, as I'm using PostgreSQL, but I'd really prefer to >> get this kind of constraint in the application side for maintainability >> sake :) Also, the application under production is still in top of MySql, >> while the one at QA was already converted to PostgreSQL. I'm still trying >> to convince my employers not to worry about the migration as we had no >> problem in the QA server ;) But that is to say that sometimes having >> constraints in the application side is also useful. If you're going to >> migrate your database for example, you'd not have to convert your triggers >> from the old database to the new one :) >> > > True, moving constraint code to the database does cause additional work > when switching databases. However, having constraint code in the > application causes additional work when having a separate application > access the same database. In my experience, having a separate application > access the same database is much more common than switching the database of > an existing application. > I guess you're right. For example, when I found a bug in Grails, I started another application that will access the same database. So, I'm not only migrating the database but also using 2 applications simultaneously to access the same database. How often should that happen? :P > While on the subject, while I agree that setting "CASCADE DELETE" is a >> better option for handling cascading, some "databases" won't allow you to >> do so. For example my production database of this application I'm >> maintained (which wasn't chosen by me) is MySql and is not using the InnoDB >> engine. That means it doesn't support foreign keys. So ActiveRecord is able >> to handle that by providing the "dependent: :delete_all" to the association >> method. So, you might be interested in considering such an option for those >> "databases" that do not support foreign keys (I guess this is only MySql >> with default engine as far as I can tell you). >> > > Sequel already has an association_dependencies plugin that is allows > similar behavior to ActiveRecord's "dependent: :delete_all" > Great, I didn't know about this. I must have over looked the plugins list. > MySQL 5.5 uses InnoDB as the default table engine I believe, > Yes, at least this is what they have announced, but this version won't be available from the main repositories in most servers. I do see it listed today in Debian experimental repositories, but I couldn't even find it in experimental a while ago when I first read about this. So, I'm not sure how much time until this future becomes present :) Maybe when no one will be using IE6 and 7 anymore ;) so hopefully in the future the people unfortunate enough to have to use > MySQL will at least have foreign keys by default. :) > > >> With regards to PostgreSQL, I gave sequel_pg a try but I couldn't notice >> any difference on my specs run total time. On the other hand, they were >> taking about 1.1s with ActiveRecord and now they're taking about 0.6s and >> that was awesome! :D >> > > sequel_pg probably won't affect spec runtime significantly. Try > benchmarking a production query where you are retrieving many rows at the > same time. :) > Okay, I see. I'll give it a try later when I get some expensive data set to load from the production database. Thanks, Rodrigo. -- You received this message because you are subscribed to the Google Groups "sequel-talk" group. To view this discussion on the web visit https://groups.google.com/d/msg/sequel-talk/-/pZhDNzHhhF4J. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/sequel-talk?hl=en.
