Hi, All of the functionality is added and everything is checked into CVS. If you find anything wrong, let me know, and I'll be glad to fix it.
Regarding your comment about Oracle 9 users wanting to use the ANSI style joins. I know it would add more properties (to the already large number), but it might be nice to be able to specify Dialect specific properties. This would allow the user to toggle which outer join style to use for this Dialect. Jon... ----- Original Message ----- From: "Gavin King" <[EMAIL PROTECTED]> To: "Jon Lipsky" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Friday, September 27, 2002 2:51 PM Subject: Re: [Hibernate] Implentation of Outer Join for Oracle > All very sound. The only likely objection is that Oracle 9 users might want > to use ANSI style joins for the few people who would have this issue can > easily subclass OracleDialect. > > At some stage it would be really nice to develop a hierarchy of classes that > model SQL statements, eg. SQLUpdate, SQLSelect, SQLSelectOrderBy, etc.... > > At present Hibernate models SQL statements with java.lang.StringBuffer, > which is what you get if you follow YAGNI too devoutly :( > > ----- Original Message ----- > From: Jon Lipsky > To: [EMAIL PROTECTED] > Sent: Friday, September 27, 2002 10:22 PM > Subject: [Hibernate] Implentation of Outer Join for Oracle > > > Hi Gavin, > > I finally have time try to add the Oracle joins stuff into the new > refactored version of Hibernate in CVS. > > I want to run my ideas by you before I do them, to make sure you agree (and > to make sure I understand your refactorings correctly :-) > > 1) Refactor the outer join generation into a seperate class so that the > current OuterJoinLoader calls a seperate class to actually create the SQL > statement fragments. > > 2) Add the ability for a dialect to specify which OuterJoinGenerator to use. > > 3) Add an OracleOuterJoinGenerator (based on the code I've already written > for the 1.1 version of Hibernate). > > 4) Modify OuterJoinLoader so that it has two possible places it can add to > the SQL statement. ie.. After the FROM part of the SQL is generated and > after the WHERE clause. So, for example, in the CollectionLoader, when it > is generating the SQL, it would do something like: > > sql = sqlSelect( > // SELECT CLAUSE > selectCollectionString(persister, alias) + > ( joins==0 ? "" : ", " + selectString(associations) ), > // FROM CLAUSE > persister.getQualifiedTableName()+' '+alias, > // OUTER JOINS PART 1 > outerJoinStringAfterFrom(associations), > // WHERE CLAUSE > whereString( persister.getKeyColumnNames(), alias ), > // OUTER JOINS PART 2 > outerJoinStringAfterWhere(associations), > // ORDER BY CLAUSE > ( persister.hasOrdering() ) ? > alias + '.' + persister.getSQLOrderByString() : > null > ); > > What do you think of that idea? Doing it this way wouldn't require the > addition of an Environment variable like my previous solution, and it would > allow us to add other outer join strategies if needed. > > Jon... > ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ hibernate-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/hibernate-devel
