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. 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. > 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. > 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" MySQL 5.5 uses InnoDB as the default table engine I believe, 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. :) Thanks, Jeremy -- 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/-/ZfXvIzsdhMgJ. 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.
