gnustep-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re[2]: gdl2: SQLExpression / Postgresql / left joins...


From: Manuel Guesdon
Subject: Re[2]: gdl2: SQLExpression / Postgresql / left joins...
Date: Sat, 26 Jul 2003 14:08:02 +0200 (CEST)

On Sat, 26 Jul 2003 13:04:41 +0200 David Ayers <address@hidden> wrote:

 >| Manuel Guesdon wrote:
 >| 
 >| >Hi,
 >| >
 >| >I've found a problem handling left/right joins with postgresql: Postgresql 
 >doesn't accept syntax like where t0.a
 >| *= t1.b
 >| >It accepts this only in FROM clause, like:
 >| >        FROM xx as t0 left join yy as t1 on t0.a=t1.b
 >| >Actually, joins are used when building joinClause and the joinClause is 
 >added to where clause. Joins are not
 >| processed in
 >| >-tableListWithRootEntity (which build from clause)
 >| >
 >| >One way to work around this will be to subclass -joinExpression and 
 >-tableListWithRootEntity in
 >| PostgresSQLExpression but
 >| >this mean, IMHO, too much code duplication.
 >| >
 >| >Another solution could be to have a method in SQLExpression like 
 >-isJoinClauseInFromClause or
 >| >-isSupportingOuterJoinInWhereClause and call this in EOSQLExpression 
 >-joinExpression and -tableListWithRootEntit
 >| to know
 >| >where we have to put joins.
 >| >
 >| >Any opinion ?
 >| >
 >| >Dave, as you've written a Postgres adaptor, how did you solved this ?
 >| >
 >| >  
 >| >
 >| Well as Dave seem to be busy, I'll give you my two cents :-)
 >| 
 >| It's a matter of deciding whether the Postgres adaptor should be a GDL2 
 >| adaptor or an EOF 3 adaptor.  I wouldn't mind either way, but what ever 
 >| we do, we should document it in the class documentation.

As turbocat made available and support a postgres adaptor for EOF 3, having 
GDL2 one available for EOF 3 may be not a
greatadvantage.


 >| If we go with EOF, then it's clear that the adaptor's SQLExpression must 
 >| override -joinExpression and -tableListWithRootEntity.  I'm not sure 
 >| whether there is too much code duplication there, as they would assemble 
 >| the tableList quite differently *if* there is a join, but can merely 
 >| return the result of calling super if there isn't.  -joinExpression 
 >| would merely return an emty string then.  Or am I missing something?

No, you're right.
I don't know if there's other databases with the same problem.
About code duplication, when removing logs, there's finally not too much.


 >| On the otherhand, I know someone is working on a real implementing 
 >| describeModelWithTableNames: for the adaptor, and it seems from a 
 >| general abstraction standpoint that a lot ot the logic could be factored 
 >| out into the super class.  If we actually relied on that, then we would 
 >| have the GDL2 adaptor again.
 >| 
 >| This all looks like we may be headed towards an EOAccess-Additions 
 >| subproject for GDL2 that could be compiled on WO 4.5.  Then we would 
 >| have the freedom to extend a we please, and make the Postgres adaptor 
 >| depend on either GDL2 or GDL2 Additions for EOF.  If that's the way we 
 >| want to go, then we (I) can look into prividong the infrastructure for 
 >| it.  Which brings us back to the Header discussion :-)

OK. I'll put the stuff in Postgres adaptor for the moment and we'll see later 
if we find better solution...


Thx

Manuel

--
______________________________________________________________________
Manuel Guesdon - OXYMIUM <address@hidden>
14 rue Jean-Baptiste Clement  -  93200 Saint-Denis  -  France
Tel: +33 1 4940 0999  -  Fax: +33 1 4940 0998





reply via email to

[Prev in Thread] Current Thread [Next in Thread]