I'm building a social networking application and I believe that issue
#010373: Several relations to the same table for PersistentObject (
http://issues.ez.no/IssueView.php?Id=10373&activeItem=9 ) limits my
ability to use PersistentObject.
I just want to verify that:
-I can't use the current version of PersistentObject,
-find out if there are any workarounds, and
-make sure that the resolution of issue #010373 will address my case when it's
fixed.
In a social network, a fundamental relationship is a user and their
friends (who are also users and have friends). So, my database schema
looks like:
<-- owner 1:1 -------
users friends
<-- friend_of 1:n ---
I'm assuming that issue #010373 applies to my case because I have 2
relations between a pair of tables. It's different from the other
examples I've read about, however, because it's also a N:M relation
(although the owner relation is 1:1 so it's not the classic N:M). The
ezcPersistentSession->getRelatedObjects() interface does not currently
allow a relation to be specified as a parameter so I assume issue
#010373 applies.
The notes in the issue description refer to 1:N relations. I'm
presenting my scenario as a test case for the #010373 fix (a modified
N:M relation).
As for a workaround, is it possible (and recommended) to mix raw SQL
and PersistentObject?
For example, in the following scenario there is a high cost to
synchronize between SQL and PersistentObject. Imagine I want to show
a user profile with friends. I need to:
-use PersistentObject to load a user
-use SQL to get the user_ids of friends
-use PersistentObject to load the friends. This would be N user object
creations (sql select statements) instead of just traversing the user
object (doing a SQL join) to get an array of related objects --
expensive in terms of database interaction!
Seems like I'm better off using raw SQL all the time, but I want to
find out what other people do.
Thanks,
Dennis Fogg
--
Components mailing list
[email protected]
http://lists.ez.no/mailman/listinfo/components
