You are viewing a plain text version of this content. The canonical link for it is here.
Posted to ojb-dev@db.apache.org by Vadim Gritsenko <va...@reverycodes.com> on 2005/03/24 19:31:24 UTC
Query and QueryByCriteria
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
Re: Query and QueryByCriteria
Posted by Brian McCallister <br...@apache.org>.
I think he was offering to just go ahead and do it himself ;-)
-Brian
On Mar 25, 2005, at 12:06 PM, 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.
>
> 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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org
Re: Query and QueryByCriteria
Posted by Vadim Gritsenko <va...@reverycodes.com>.
Jakob Braeuchi wrote:
> hi vadim,
>
> ojb 1.1 supports QueryByExample where the criteria is built based on the
> example.
Ok, good. Is there a way to back port these, or some of these, changes back to
the OJB 1.0 branch?
I'll have to take a look at 1.1 and see how can I port my patches to that... So
far I was working with 1.0 branch.
Vadim
> Vadim Gritsenko schrieb:
>
>> Jakob Braeuchi wrote:
>>
>>> hi vadim,
>>>
>>> Vadim Gritsenko schrieb:
>>>
>>>> Jakob Braeuchi wrote:
>>>>
>>>>> i'd prefer to have interfaces for Query, QueryByCriteria,
>>>>> QueryByExample,
>>
>>
>> Here, you mean QueryByExample or QueryByIdentity? In getExampleObject
>> in current
>> QueryByExample actually is never used as *example*, but rather identity
>> (PersistenceBrokerImpl, lines 549, 1425 in 1.0.1). So to me, it makes
>> sense to have:
>>
>> public interface QueryByIdentity {
>> Identity getIdentity();
>> }
>>
>>
>>>>> and ReportQuery. the current interface Query is a mix of the first
>>>>> three interfaces.
>>>>
>>>>
>>>>
>>>> Does it mean you plan to trim Query interface?
>>>
>>>
>>>
>>> yes, it will onlycontain getSearchClass() and the paging information.
>>
>>
>>
>> So that means that SqlQueryStatement will depend on QueryByCriteria
>> interface
>> instead of QueryByCriteria class, that's good.
>>
>> It also means that QueryByExampleImpl class should implement both
>> QueryByExample
>> interface and QueryByCriteria interface. Am I on track (please also
>> see below)?
>>
>>
>>>>> how would your extended Query-interface look like ?
>>>>
>>>>
>>>>
>>>> So far it's class, named QueryByFKCriteria, and it is simplification
>>>> of the QueryByCriteria class. It takes (Class, String[] names,
>>>> String[] values) as constructir arguments and internally creates
>>>> Criteria in the form of "name=value AND ...".
>>>
>>>
>>> imo there's already a QueryByIdentity that does something similar.
>>
>>
>> Some questions regarding this.
>>
>> I see that current QueryByIdentity class does not build a Criteria out
>> of the
>> identity object. Do you think it should build one in the way similar to
>> QueryByCriteria.buildCriteria [1]? It should consider only primary key
>> fields,
>> not all fields.
>
>
> the building of criteria has been deferred because we need a pb to do
> so. in ojb 1.1 this is done in the method preprocess().
>
>>
>> The query I need actually can be an extension of the QueryByIdentity
>> class, with
>> only one difference: instead of building criteria only for primary key
>> fields,
>> it will build criteria using all available fields, same as in
>
>
> there's only a simple problem to be solved: the primitive java types :(
> my current implementation uses all non-null values of the example
> object. the correct handling of the primitives still needs to be defined.
>
> jakob
>
>> QueryByCriteria.buildCriteria [1]. So, it seems to me that it can be
>> named
>> QueryByExample and it should extend QueryByIdentity.
>>
>> Given the above, both these Queries would implement QueryByCriteria
>> interface -
>> if you to split Query interface into three different once - this will
>> provide a
>> way to execute these queries using SqlQueryStatement.
>>
>> Does the above make sense to you?
>>
>> Thanks,
>> Vadim
>>
>> [1] Around line 150 in QueryByCriteria:
>> private static Criteria buildCriteria(Object anExample)
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org
Re: Query and QueryByCriteria
Posted by Jakob Braeuchi <jb...@gmx.ch>.
hi vadim,
ojb 1.1 supports QueryByExample where the criteria is built based on the
example.
Vadim Gritsenko schrieb:
> Jakob Braeuchi wrote:
>
>> hi vadim,
>>
>> Vadim Gritsenko schrieb:
>>
>>> Jakob Braeuchi wrote:
>>>
>>>> i'd prefer to have interfaces for Query, QueryByCriteria,
>>>> QueryByExample,
>
>
> Here, you mean QueryByExample or QueryByIdentity? In getExampleObject in
> current
> QueryByExample actually is never used as *example*, but rather identity
> (PersistenceBrokerImpl, lines 549, 1425 in 1.0.1). So to me, it makes
> sense to have:
>
> public interface QueryByIdentity {
> Identity getIdentity();
> }
>
>
>>>> and ReportQuery. the current interface Query is a mix of the first
>>>> three interfaces.
>>>
>>>
>>> Does it mean you plan to trim Query interface?
>>
>>
>> yes, it will onlycontain getSearchClass() and the paging information.
>
>
> So that means that SqlQueryStatement will depend on QueryByCriteria
> interface
> instead of QueryByCriteria class, that's good.
>
> It also means that QueryByExampleImpl class should implement both
> QueryByExample
> interface and QueryByCriteria interface. Am I on track (please also see
> below)?
>
>
>>>> how would your extended Query-interface look like ?
>>>
>>>
>>> So far it's class, named QueryByFKCriteria, and it is simplification
>>> of the QueryByCriteria class. It takes (Class, String[] names,
>>> String[] values) as constructir arguments and internally creates
>>> Criteria in the form of "name=value AND ...".
>>
>>
>> imo there's already a QueryByIdentity that does something similar.
>
>
> Some questions regarding this.
>
> I see that current QueryByIdentity class does not build a Criteria out
> of the
> identity object. Do you think it should build one in the way similar to
> QueryByCriteria.buildCriteria [1]? It should consider only primary key
> fields,
> not all fields.
the building of criteria has been deferred because we need a pb to do
so. in ojb 1.1 this is done in the method preprocess().
>
> The query I need actually can be an extension of the QueryByIdentity
> class, with
> only one difference: instead of building criteria only for primary key
> fields,
> it will build criteria using all available fields, same as in
there's only a simple problem to be solved: the primitive java types :(
my current implementation uses all non-null values of the example
object. the correct handling of the primitives still needs to be defined.
jakob
> QueryByCriteria.buildCriteria [1]. So, it seems to me that it can be named
> QueryByExample and it should extend QueryByIdentity.
>
> Given the above, both these Queries would implement QueryByCriteria
> interface -
> if you to split Query interface into three different once - this will
> provide a
> way to execute these queries using SqlQueryStatement.
>
> Does the above make sense to you?
>
> Thanks,
> Vadim
>
> [1] Around line 150 in QueryByCriteria:
> private static Criteria buildCriteria(Object anExample)
>
>
> ---------------------------------------------------------------------
> 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
Re: Query and QueryByCriteria
Posted by Vadim Gritsenko <va...@reverycodes.com>.
Jakob Braeuchi wrote:
> hi vadim,
>
> Vadim Gritsenko schrieb:
>
>> Jakob Braeuchi wrote:
>>
>>> i'd prefer to have interfaces for Query, QueryByCriteria,
>>> QueryByExample,
Here, you mean QueryByExample or QueryByIdentity? In getExampleObject in current
QueryByExample actually is never used as *example*, but rather identity
(PersistenceBrokerImpl, lines 549, 1425 in 1.0.1). So to me, it makes sense to have:
public interface QueryByIdentity {
Identity getIdentity();
}
>>> and ReportQuery. the current interface Query is a mix
>>> of the first three interfaces.
>>
>> Does it mean you plan to trim Query interface?
>
> yes, it will onlycontain getSearchClass() and the paging information.
So that means that SqlQueryStatement will depend on QueryByCriteria interface
instead of QueryByCriteria class, that's good.
It also means that QueryByExampleImpl class should implement both QueryByExample
interface and QueryByCriteria interface. Am I on track (please also see below)?
>>> how would your extended Query-interface look like ?
>>
>> So far it's class, named QueryByFKCriteria, and it is simplification
>> of the QueryByCriteria class. It takes (Class, String[] names,
>> String[] values) as constructir arguments and internally creates
>> Criteria in the form of "name=value AND ...".
>
> imo there's already a QueryByIdentity that does something similar.
Some questions regarding this.
I see that current QueryByIdentity class does not build a Criteria out of the
identity object. Do you think it should build one in the way similar to
QueryByCriteria.buildCriteria [1]? It should consider only primary key fields,
not all fields.
The query I need actually can be an extension of the QueryByIdentity class, with
only one difference: instead of building criteria only for primary key fields,
it will build criteria using all available fields, same as in
QueryByCriteria.buildCriteria [1]. So, it seems to me that it can be named
QueryByExample and it should extend QueryByIdentity.
Given the above, both these Queries would implement QueryByCriteria interface -
if you to split Query interface into three different once - this will provide a
way to execute these queries using SqlQueryStatement.
Does the above make sense to you?
Thanks,
Vadim
[1] Around line 150 in QueryByCriteria:
private static Criteria buildCriteria(Object anExample)
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org
Re: Query and QueryByCriteria
Posted by Jakob Braeuchi <jb...@gmx.ch>.
hi vadim,
Vadim Gritsenko schrieb:
> Jakob Braeuchi wrote:
>
>> 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.
>
>
> Does it mean you plan to trim Query interface?
yes, it will onlycontain getSearchClass() and the paging information.
>
>
>> how would your extended Query-interface look like ?
>
>
> So far it's class, named QueryByFKCriteria, and it is simplification of
> the QueryByCriteria class. It takes (Class, String[] names, String[]
> values) as constructir arguments and internally creates Criteria in the
> form of "name=value AND ...".
imo there's already a QueryByIdentity that does something similar.
jakob
>
> After that, if foreign-key stored procedure is declared on the class, my
> queries are executing using this stored procedure. Otherwise,
> SqlSelectStatement generates select as usual.
>
>
>> immutable queries is a problem in the current version of ojb because
>> some of the criteria are generated at runtime (ie. IdentityCriteria),
>> see preprocess.
>
>
> Ok
>
> Vadim
>
>
>> 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
>
>
> <snip/>
>
>
> ---------------------------------------------------------------------
> 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
Re: Query and QueryByCriteria
Posted by Vadim Gritsenko <va...@reverycodes.com>.
Jakob Braeuchi wrote:
> 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.
Does it mean you plan to trim Query interface?
> how would your extended Query-interface look like ?
So far it's class, named QueryByFKCriteria, and it is simplification of the
QueryByCriteria class. It takes (Class, String[] names, String[] values) as
constructir arguments and internally creates Criteria in the form of "name=value
AND ...".
After that, if foreign-key stored procedure is declared on the class, my queries
are executing using this stored procedure. Otherwise, SqlSelectStatement
generates select as usual.
> immutable queries is a problem in the current version of ojb because
> some of the criteria are generated at runtime (ie. IdentityCriteria),
> see preprocess.
Ok
Vadim
> 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
<snip/>
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org
Re: Query and QueryByCriteria
Posted by Jakob Braeuchi <jb...@gmx.ch>.
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
Re: Query and QueryByCriteria
Posted by Vadim Gritsenko <va...@reverycodes.com>.
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
Re: Query and QueryByCriteria
Posted by Jakob Braeuchi <jb...@gmx.ch>.
hi vadim,
query-refactoring is already on my todo-list. i prefer to convert
QueryByCriteria into an interface and to have a QueryByCriteriaImpl class.
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
Re: Query and QueryByCriteria
Posted by Vadim Gritsenko <va...@reverycodes.com>.
Jakob Braeuchi wrote:
> 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.
Yes, I know. In my branch this method is implemented using my QueryByFKCriteria,
so it can use stored procedures instead of plain SQL only.
> btw. QueryFactory#newQuery(Object example_or_identity) has been
> deprecated in is replaced either by newQueryByIdentity or newQueryByExample
That's Ok.
Thanks,
Vadim
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org
Re: Query and QueryByCriteria
Posted by Jakob Braeuchi <jb...@gmx.ch>.
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: 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
Re: Query and QueryByCriteria
Posted by Vadim Gritsenko <va...@reverycodes.com>.
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));
* 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: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org
Re: Query and QueryByCriteria
Posted by Brian McCallister <br...@apache.org>.
Jakob would be the expert on the criteria and query stuff, so the best
commentary will come from him.
I think I'd prefer to see the query stuff there now cleaned up to do
what you need rather than have another implementation. As Jakob said,
moving it to an interface and removing the need for internal casts
would be my off-the-cuff comments.
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?
-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: 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