On 3/9/07, Jud Dagnall <[EMAIL PROTECTED]> wrote:
> I would expect that regardless of how the query was constructed, any
> results (projects) returned would be accurate, meaning that they would
> reflect the the state of things in the database at the time that the
> query was executed.
But what you're saying with this:
query => [ 'employees.name' => 'jud' ],
is "filter the 'employees' collection, leaving only the employees
named 'jud'". That's not what you really want. What you want is a
subselect. Requiring and then filtering the employees collection is
sort of close to what you want because it does limit the t1 rows
(i.e., the projects returned), but the collection filtering
side-effect clashes with your intent.
This is just how filtering collections in a Manager query works, and
unfortunately there's no similarly terse way to "filter primary table
rows based on the contents of a collection" because that requires
subselects.
> It is definitely surprising behavior that $project->employees would not
> reflect the state of the database, and it would be great if it was (at
> least) clearly documented.
The collection of objects returned does reflect the query used to
fetch them, however :) Once you start filtering collection on a
per-call basis, the formerly tidy definition of each collection (e.g.,
$project->employees containing "all employees on a project")
necessarily goes by the wayside. People still want to do it, however,
and would be upset if the Manager, say, added an implicit fetch_only
=> ... param when it saw that a collection was being filtered.
> So if I understand correctly, adding a tags table (project_tag_maps)
>
> my ($project) = My::Project::Manager->get_projects(
> query => [ 'employees.name' => 'jud' ],
> require_objects => [ 'employees', 'tags' ]
> );
>
> $project->employees( ) - doesn't match DB
> $project->tags( ) - matches DB
>
> query( ) really means limit not only the projects returned, but also
> filter any related objects.
Literally, it means to add a filter on the employees.name column to
the WHERE clause of the query. That, in turn, limits the employees
that are returned.
In the end, the only real guarantee offered by Manager->get_objects()
is that it'll return a tree of objects. Those objects may be sparsely
populated, and object collections may be partially filled in, but this
is considered a feature :)
Real support for subselects is on my long-term list. Then you can
really say what you mean in a Manager method call. In the meantime,
the existing behavior is actually useful in other situations, and
there are a few alternatives for the subselect case as described in my
last message.
-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
