hi vadim,
i'd prefer to have interfaces for Query, QueryByCriteria, QueryByExample, and ReportQuery. the current interface Query is a mix of the first three interfaces.
how would your extended Query-interface look like ?
immutable queries is a problem in the current version of ojb because some of the criteria are generated at runtime (ie. IdentityCriteria), see preprocess.
jakob
Vadim Gritsenko schrieb:
Jakob Braeuchi wrote:
hi vadim,
query-refactoring is already on my todo-list. i prefer to convert QueryByCriteria into an interface and to have a QueryByCriteriaImpl class.
You don't want to extend Query interface then, do you?
What do you think about possibility of immutable Query objects? It might be too complex to implement, though...
Vadim
jakob
Vadim Gritsenko schrieb:
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]
