Thanks John. In this particular case, the only object modified is the object
sent to the callback, so I'm probably safe in this case—but you probably saved
my some-point-in-the-future ass with that valuable piece of info :).
Any thoughts on modifying the relationship join column without exposing
There can be issues if you modify other objects inside lifecycle callbacks
(a callback won't be called on that object). I would recommend doing the
mods in validateForSave instead.
On Thu, Apr 4, 2019 at 6:44 AM Hugi Thordarson wrote:
> Yes, this would have been a good idea :). Unfortunately the
Yes, this would have been a good idea :). Unfortunately the model (containing
dozens of tables and hundreds of relationships) is already completely modeled
using relationships and makes heavy use of them (for expressions, ordering,
prefetching etc. etc.)
The Cayenne-project was originally creat
My guess would be “no”.
I suggest you don’t model the relationships until the foreign systems are fixed
or removed. In the meanwhile, I would implement methods as the relationships,
that would know if there’s a fictitious value or not and return NULL for the
relationship. When the other systems
I spoke a little too soon—my solution isn't sufficient, who'd have thunk it :).
Some of the columns with "fictional null values" are used in relationships. For
example, I can have an invoice with customer_id "-1" to indicate that there's
no related customer.
As I'm done cleaning up the DB, thes
Hi all,
I'm currently working on a legacy system. The DB has a lot of columns where
null should actually be allowed, but instead those fields are non-nullable and
get other values (empty string, "0", "-1" etc) written to them to indicate the
absence of a value. Yay.
Unfortunately I can't just d
