On 10/7/05 10:30 AM, Uwe Voelker wrote: >> ARRAYREF should be a reference to an array of table names or "tN" table >> aliases. > > Btw. this morning I had the following idea: > > Allow the name of the relation too. For the pod example this would be > 'prices' because: Product---(prices)-->Price. (Unfortunately the Price > table is 'prices' too, so this is a bad example.) But by allowing this > the user could completely leave out the table name or the t2, t3 alias. > The same string is used by 'with_objects' and 'require_objects'.
I worry about ambiguity among table an relationship names, but I've added the change anyway because I think it's useful and there won't be any conflicts in the common case. If there is any overlap, the all applicable tables will be included. > And now for "query": > Instead of table alias or table name also allow the above 'relation > name' (or the class name too - I'm not quite sure if this is allowed > now). If no prefix is given, use 't1' (main object), all other columns > need to be prefixed. Adding support for relationship names actually introduces ambiguity here. Now when faced with a prefix, it could be a table alias, a table name, or a relationship name, all of which can overlap. While I think this won't be too bad in the limited scope of the "distinct" param, I worry about it being added to the actual query params. Hm, I guess I can break out my secret ambiguity-breaker weapon and just document the tn_... column name aliases :) -John ------------------------------------------------------- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl _______________________________________________ Rose-db-object mailing list Rose-db-object@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rose-db-object
