cayenne-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Durchholz, Joachim" <>
Subject RE: Can I specify join type for relationships in the model?
Date Wed, 26 Oct 2011 10:48:49 GMT
> I don't think we had a discussion. We can have it now.

Nice - the "that's by design" bit made me fear it's not negotiable anymore.

> In this particular case my thinking is that relationship
> itself does not have any particular "join semantics"...
> It is always a match between two keys. If you just need
> to find objects related to a given object, using outer
> join never makes sense.

Hmm... that's interesting.

I had thought that OF COURSE you need to specify optionality on relationships, but it seems
to be far less a case than I thought.

Let's enumerate use cases where the optionality of a relationship's side might be relevant.

For automatic SELECTs by Cayenne, I see one use case: if the application holds a record that's
a grandchild, and you access the grandparent, Cayenne could optimize the outer join between
parent and grandparent table into an inner join if it knew that the to-1 relationship from
parent to grandparent is mandatory. (Inner joins give the query planner of the database more
options. More options means better plans, but maybe also more fruitless optimization planning,
so it's a mixed blessing - also, grandchild-to-grandparent selects tend to not be bulk transfers,
so this use case is a rather weak argument.)

What's the case for write access? I.e. INSERT/UPDATE/DELETE?

Here, optionality information is very relevant for determining action order: you delete the
optional record before you delete the nonoptional one, and you create the nonoptional record
before creating the optional one.
However, for a 1:N relationship, the N side is always optional, so there is a valid ordering
available. Telling Cayenne that the 1 side is optional as well would give it more freedom
to reorder writes, but it already has a valid order and doesn't need an additional one.
Then there's 1:1 relationships. If one side is optional, then it's just a case of 1:N with
the additional constraint N<=1. If both sides are mandatory, we're in trouble - Cayenne
does not know in which order to do the updates (and most databases will complain, since they
do their consistency checks immediately instead of at end-of-transaction, so you can't INSERT
into the left table because there is no record in the right table yet, and vice versa).

The other point for optionality information is that Cayenne could do consistency checks before
writing to the database.
(I don't know whether Cayenne does.)
If Cayenne knows, it can avoid getting hit by SQLExceptions from constraint violations. This
could help Cayenne if it does exception analysis, such as would be needed to activate the
various workarounds needed as Oracle reports rollback segment problems.
On the con side, for the application, it doesn't matter much to the application whether it
gets hit by an SQLException or a Cayenne-generated consistency exception.

> Where it does make sense is in
> qualifiers. But this makes it a property of a qualifier,
> not the relationship.

It makes it a property of the qualifier, but per se, that does not preclude it as a property
of the relationship.

> In generally it is often hard to find such single place
> for many ORM properties. There's always a concern that
> anything beyond basic DB mapping is really a property of
> the execution context (e.g. it is different per-application,
> per-session, per-query, etc. - a good example is entity
> callbacks/listeners adding behavior to the mapping). So
> this often becomes a question of whether "one size fits all".

I fully agree with that point of view.


View raw message