On Monday, January 19, 2015 at 10:01:52 PM UTC-8, Valentin Syrovatskiy
wrote:
>
> Thanks for answer. I understood, this is planned behaviour. But there are
> some issues with it:
>
> 1. it changed silently in minor release, so some code no more works as
> expected. This is not problem with single application but may be problem
> with framework-based application when framework requires Sequel. As for me
> I got bug with NULL in new record while I tested same code before and got
> "[]" (empty js-array) in same cell.
>
It didn't change silently, the change to update the underlying columns
before validation was mentioned in the 4.13.0 release notes. However, the
change was made to fix a bug, it wasn't anticipated that people would be
relying on the previous behavior. This is the reason it was mentioned in
the other improvements section instead of the backwards compatibility
section. Knowing what I know now, it would have been mentioned in the
backwards compatibility section as well.
>
> 2. it confuse hooks logic:
> class Test < Sequel::Model(:tests)
> plugin :serialization, :json, :data
>
> def before_save
> self.data ||= []
> self.name ||= 'bar'
> super
> end
> end
>
>
> t = Test.create()
> p t
>
> will return #<Test @values={:id=>1, :name=>"bar", :data=>nil}>
> ie :name field was changed but :data was not! Not intuitive.
>
Agreed, this is unfortunate. But unless you want to serialize twice, you
can't both validate the serialized data and change the deserialized data
after validation. If you want to keep the logic in before_save and don't
mind serializing twice, call serialize_deserialized_values before calling
super in before_save.
> 3. As for auto_validations plugin. I consider there are two types of
> possible validation: high-level (for unserialized data) and low-level (for
> raw data before put it to DB). High-level validation can be applied to be
> sure username filled or be sure currency specified with price. Low-level
> validation can be applied to sure raw data correct according DB/schema
> requirements. Thus rational save sequence is: high-level validation ->
> before_save modification -> serialization -> low-level validation -> query.
> Auto_validations plugin is low-level.
>
With Sequel, there is only one type of validation. Making the general save
logic significantly more complex to work around an issue in the
serialization plugin is not a good idea IMO.
FWIW, I'm not aware of other ruby ORMs that implement your "rational" save
sequence, the ones I am aware of do not differentiate between high-level
and low-level validations.
> 4. Just a question. Why _before_validation, not before_validation?
>
Because before_validation is not called if validation is skipped.
_before_validation is always called, even if validations are skipped.
IMO, the serialization plugin is a bad idea in general, for a number of
reasons (queryability, integrity). The idea is similar to trying to
enforce foreign key or check constraints in your application instead of in
the database. If you use a database and adapter with support for richer
datatypes (such as PostgreSQL's json/jsonb columns with the Sequel's
pg_json extension), you won't have the problems that the serialization
plugin has, and there will be numerous other advantages.
Thanks,
Jeremy
--
You received this message because you are subscribed to the Google Groups
"sequel-talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/sequel-talk.
For more options, visit https://groups.google.com/d/optout.
