hi vadim,
Vadim Gritsenko schrieb:
Brian McCallister wrote:
I think I'd prefer to see the query stuff there now cleaned up to do what you need rather than have another implementation.
QueryByCriteria is too complex for what I need. I need a query where criteria has very strict structure: it's list of object fields values. This query covers two use cases:
* Query By Example (not by identity!):
A a = new A(); a.name = 'John'; broker.getCollectionByQuery(QueryFactory.newQuery(a));
there's already a method QueryFactory#newQueryByExample() available to build a query based on an example object.
btw. QueryFactory#newQuery(Object example_or_identity) has been deprecated in is replaced either by newQueryByIdentity or newQueryByExample
jakob
* Query By Primary Key
* Query By Foreign Key
Using this query, I'd implemented retrieval of references, and 1:N relations through stored procedures.
As Jakob said, moving it to an interface and removing the need for internal casts would be my off-the-cuff comments.
Any chance of extending Query interface?
The ability to query by calling a stored proc directly would be great, and that subject has come up before. What do you see the API looking like?
See above...
Vadim
-Brian
On Mar 24, 2005, at 1:31 PM, Vadim Gritsenko wrote:
Hi All,
I would like to introduce new Query implementation, which is a simplified version of the QueryByCriteria - it does not support arbitrary criterias but only criterias with certain structure [1].
While working on impementation, I noticed, that despite the fact that there is base interface - Query - OJB relies in many parts on particular class - QueryByCriteria. So for my query implementation I have several ways of working this around:
* Extend my query class from QueryByCriteria and override some methods to disable extra functionality. OJB internals will remain unchanged, mostly, and will still rely on QueryByCriteria.
* Introduce base abstract class which replaces QueryByCriteria. OJB internals can rely on this abstract class instead of concrete QueryByCriteria class with lots of implementation details.
* Extend Query interface to incorporate methods introduced in QueryByCriteria. OJB internals can rely on interface instead of concrete class.
* Any other good approach which I missed?
Now question, which way is the most appealing way to OJB developers? My goal is to have these changes incorporated back into OJB, so I'd like to take the approach which is preferred by OJB team.
Another question I had is of more abstract nature... Why OJB's Query implementations are not immutable objects? It does prevent caching of Query obhects, multithreaded usage of Query objects, etc. To me, ideal OJB architecture would rely on Query interface and treat Query instances as immutable objects - so that new Query implementations can be plugged in easily, and Query objects themselves can be passed on by reference without any problems.
[1] This new Query will implement query-by-primary-ley and query-by-reference functionality - with support of plain SQL as well as stored procedures. As a side effect, it will provide some query-by-example-object functionality. Current QueryFactory.newQuery(Object example) is confusing to me - it can not really create a query by example object, only query by primary key, right?
Thanks, Vadim
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
