On 7/29/06 4:21 PM, Jonathan Vanasco wrote:
> what we should have asked is for the planner to conditionally join
> the table -- so we get the null values if the condition isn't met
Ah, gotcha.
>> If a were to add the ability to augment the join conditions in a Manager
>> query, what would the syntax be like?
>
> [...] perhaps with_objects/ require objects checks to see if the item is
> a scalar (current behavior) or an array/hashref (conditional behavior)
>
> with_objects=> [
> normal_join,
> conditional_join=> [ ]
> ]
You know, now that I think about it, this concept of modifying query that
determines which objects are in a related set on a per-call basis goes
against the semantics of the existing Manager interface.
As things stand, the ideas is that named relationships (or fks, same deal)
define the set of related objects through their column maps. The Manager
interface works by asking for those named sets of related objects, either
only the objects with those related objects (require_objects), or all
objects, even if they have none of those related object (with_objects).
This has an important link to the meaning of the relationship methods on
individual objects. When I say:
@addrs = $person->addresses;
that means "get all of the objects related through a particular named
relationship." Similarly, this:
$person->addresses(@addrs);
means "set the entire list of related objects," so much so that when I do:
$person->save;
any existing related address objects will be deleted to make way for the new
set in @addrs. They'll be deleted according to the same rules that governed
the fetch when "@addrs = $person->addresses;" was run. That is, the static
set of join conditions set in the "addresses" relationship.
Now it's okay to have a variety of conditions, but they each require a new
named relationship:
@addrs = $person->new_york_addresses;
The join conditions on the "new_york_addresses" relationship could
conceivably have a "addresses.state = 'NY'" join condition. And so this:
$person->new_york_addresses(@addrs);
$person->save;
would delete all the existing related addresses with a state of NY and add
the new set. The point is that these relationships are well-defined sets.
The methods that service them are not a means to arbitrarily query the
database, because the results are not simply returned. They're assigned to
the object as child objects stored in well-defined locations.
So, in the Manager, it's not in fitting with this system to say "get me all
the objects related through the 'addresses' relationship, but oh yeah, here
are a few more conditions." Imagine if you did that:
@persons =
Person::Manager->get_persons(
with_objects => [ addresses => [ "oh yeah, and..." ] ]);
and then later in the code, this appeared:
$p = $persons[0];
@addrs = $p->addresses; # WARNING: not the full list!
# Modify @addrs in some way: add, remove items, whatever
...
$p->addresses(@addrs);
$p->save; # UH OH! What just happened here?
The semantics of the code above *should* be what I describe earlier, but
they're not because of the modified join in the Manager query.
I think the only valid "simple" solution right now is to allow more complex
join conditions in the relationship rules themselves. Beyond that, I'll
have to think about it...
(suggestions welcome!)
-John
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Rose-db-object mailing list
Rose-db-object@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rose-db-object
