On 7/12/06 10:30 AM, Danial Pearce wrote:
> I'm seeing a deflate trigger being called when you do a save() even
> if the column that has the trigger has not had a value set, nor does
> it have a default value. This is not a huge issue, i don't really
> have a problem with it, was just an observation really.
This behavior allows undef values to be deflated. That may sound strange,
but it is possible that undef could become something else during a deflate
step for a particular column type (e.g., an empty set or array rather than
an NULL).
> I'm also seeing an inflate trigger being called when you do a get on
> a field that you just set. I.e. the value you are getting back should
> not need to be inflated because it hasn't touched the database yet.
>
> $foo->bar('foobar'); ## no inflate/deflate done yet.
> print $foo->bar; ## triggers an inflate.
> $foo->save; ## triggers a deflate.
It's not currently possible for the object to know whether the value that
was just set is already inflated or not. (A user of the object can pass in
either type of value.) So when you get the value in the second step above,
the inflate trigger is run to ensure that the value is properly inflated
before it's returned. As the documentation for the "inflate" trigger event
says:
http://search.cpan.org/~jsiracusa/Rose-DB-Object-0.74/lib/Rose/DB/Object/Met
adata/Column.pm#TRIGGERS
"Note that the value to be inflated may have come from the database, or from
end-user code. Be prepared to handle almost anything."
Of course, the docs also say that inflate is triggered "when a column value
that came directly from the database is retrieved for some purpose other
than storage in the database." I'll fix that wording in the next release,
removing the "...that came directly from the database..." part.
> This causes some problems if you are encrypting your field with your
> triggers. When you do the second step there, it is triggering the
> inflate, which would typically be a decrypt type method, which in
> this particular case will try to decrypt something that is not
> encrypted. Then when the save comes along, it is encrypting the now
> garbled value.
During a column accessor call, remember that you have a way to tell if the
"consumer" of the value is the database or something else. Check out the
is_saving() function in Rose::DB::Object::Util.
http://search.cpan.org/~jsiracusa/Rose-DB-Object-0.74/lib/Rose/DB/Object/Uti
l.pm#is_saving
Similarly, is_loading() tells you if the value being set is coming from the
database. Using these methods, you can make more informed choices inside
your trigger routines.
-John
-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Rose-db-object mailing list
Rose-db-object@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rose-db-object
