db-ojb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jakob Braeuchi <jbraeu...@gmx.ch>
Subject Re: Query and QueryByCriteria
Date Sun, 27 Mar 2005 09:04:39 GMT
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: ojb-dev-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-dev-help@db.apache.org
> 
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org


Mime
View raw message