Re: Joins -- Details
Franck Routier <[email protected]> Wed, 25 Mar 2009 11:31:41 +0100
| Newsgroups | gmane.comp.java.orm.simpleorm |
|---|---|
| Message-ID | <1237977101.23736.45.camel@franck-laptop> |
Hello Anthony,
> Details:-
>
> + SRelation is an odd name in English. "Relation" in relational
> algebra is just a fancy word for Table. It does not mean the
> relationship between tables. And there could be several SRelations for
> the same Table. I would suggest the SQL term SAlias, or maybe
> SQueryTable.
I picked SQueryTable and made it a first level class :
simpleorm.dataset.SQueryTable
>
> + retrieveRecord: if ( fMeta.getRecordMeta() != inst.getMeta())
> { cannot be right. What about joining Emp to Manager? Needs to know
> about Relations.
>
This test is indeed useless now, as we know from the SQueryTable what
fields are to be retrieved from the resultset, and we pass this
information to the method via the selectList and beginIndex parameters.
Joining Emp to Manager works, because each has its own SQueryTable, and
each SQueryTable knows which column it want from the resultset.
> ++ Due to the above I think that you need to push SRelation up through
> the code so that it is created by findInDatabase and not in
> SDriver.select.
>
Well, we could do that, but it is not really needed. When we call
retrieveRecord from findInDatabase, we know we are only working on one
table (no join, etc.), so we know we want all fields from index 1 to
selectList.length.
No real need to create a SQueryTable for that (but possible).
> I had tried not to create too many objects during query processing for
> performance reasons. But given where we are maybe we should just push
> the whole SQuery object up to findInDatabase. Would reduce the number
> of parameters to selectSQL, and the performance impact is probably
> negligible. Might clean up SQuery slightly eg. create the
> queryParameters List lazily. I'd like to profile this a bit, eg.
> measure your final version against the old version doing simple finds
> on HSQLDB (which is very fast and will highlight issues).
Performence seems to be quite ok now, but profiling would certainly be
interesting.
> + I'd personally prefer mainAlias to be mainRelation of type
> SRelation.
ok, changed it to mainTable of type SQueryTable.
Also cleaned up code for checkFieldOkToUse().
>
> + I am concerned about your use of SRelation.mustQuote. Generating
> queries like
> FROM FOO "FOO", ...
> is unusual at least, and so likely to cause compatibility problems
> with other databases.
Well, we won't generate 'from foo "foo"' unless user told us to quote
this table name in SRecordMeta, so we will have :
from "foo" "foo"
or rather
from "fo%o" "fo%o" for example (and using non ascii characters in table
names is calling for problems anyway, but that's another problem).
So the only case when we quote the alias is when it is equal to a table
name that the user wants to be quoted. In every other case, we don't
quote.
> Maybe if the alias is the same as the table name simply don't specify
> it at all?
> Maybe generate default aliases being the first letter of the table
> followed by the number of tables in the query?
> Eg. D2 if Department is the first joined table? (Just use
> relations.size()).
> Would make the default generated queries neater.
> (Then mustQuote can go completely.)
>
Yes, but then the problem is that the user don't know what alias has
been assigned to its table (unless he counts the number of tables
himself, but then adding a new join later can change it all), and he
might need it in rawPredicate or rawJoin or rawOrderBy.
That why I gave up generating aliases in the first place : SQuery always
returns itself, so it is difficult to tell the user what alias would
have been generated, and he might need it...
> + Renamings are incomplete, eg. appendTableName.
Changed SRelation to SQueryTable, so let appendTableName as is.
>
> + SException.Error("Duplicate alias in query. Table not added.");
> Should say which alias.
Done
>
> + Maybe "SRelation" should go into its own file. SQuery is getting
> pretty big.
Done.
Reagards,
Franck
------------------------------------
Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/SimpleORM/
<*> Your email settings:
Individual Email | Traditional
<*> To change settings online go to:
http://groups.yahoo.com/group/SimpleORM/join
(Yahoo! ID required)
<*> To change settings via email:
mailto:[email protected]
mailto:[email protected]
<*> To unsubscribe from this group, send an email to:
[email protected]
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/