Re: 1:M querys constraints
contents, without requiring a query syntax to be defined in XML. -steve Steve Clark Technology Applications Team Natural Resources Research Center/USGS [EMAIL PROTECTED] (970)226-9291 Date: Fri, 21 Feb 2003 17:49:32 +0100 From: Jakob Braeuchi [EMAIL PROTECTED] To: OJB Users List [EMAIL PROTECTED] Subject: Re: 1:M querys constraints hi bill, what kind of restrictions woukd you need in the collection-descriptor ? do we need the full blown criteria there ? have you already any ideas about the definition of these restrictions ? i'm asking these questions because i do not want to parse restrictions in the collection-descriptor. i prefer a simpler solution like : restriction field=firstname operation== value=Mark / restriction field=lastname operation=like value=M% / how could we handle 'AND' / 'OR' ? what do yout think about ? jakob - 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] - 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]
Re: 1:M querys constraints
Hi,
I would agree with Steve's approach. I think it would require fairly
extensive configuration addition to metadata to support all
possible types of restrictions, as they can reference hard coded
values, as well as references to child and/or parent fields
(with appended hard coded tokens like '%' for like restrictions),
as well as AND / OR, etc.
On the other hand, having a wholly custom query defined for
a collection may be an overkill for a simple restriction. Perhaps,
it may simplify matters, if there is a provision for a callback class
that would modify a naturally existing association, like so:
collection-descriptor
name=projects
elementClass=gov.doi.cap.ojb.dataobjects.Project
..
constraint class=my.custom.query.restrictor
parameter key=key1 value=value1/
parameter key=key2 value=value2/
/constraint
/collection-descriptor
The query restrictor would get an access to the already existing
Query and can add or remove terms from it.
In any case, there is still an issue of how to pass dynamic
parameters for query restriction at runtime. Any other options besides metadata
manipulation?
It would be nice to do something like this:
Engineer e = get engineer from data store
e.setProjectCollectionConstraints( firstDate, secondDate );
Iterator it = e.getProjects();
while( it.hasNext() ) {
...
}
In this case the restrictor callback or query builder would have
to have an access to the instance of the object that 'originates'
the query. Any ideas?
--Bill.
Here's an idea on the collection restriction discussion. How about something
like this:
/**
* Interface implemented by classes which are used to create a custom
* query for the contents of a
collection property, when the usual
* fk/pk approach is insufficient.
*/
interface org.apache.ojb.broker.query.QueryBuilder
/** Build the query to retrieve the specified collection property
*/
Query buildQuery(Object obj, ClassDescriptor cld, CollectionDescriptor cds);
}
class PersistenceBrokerImpl {
private void retrieveCollection(...) {
if (cds.getQueryBuilder()
!= null)
{
fkQuery = cds.getQueryBuilder.buildQuery(obj, cld, cls);
}
else if (cds.isMtoNRelation())
{
fkQuery = getMtoNQuery(obj, cld, cds);
}
else
{
fkQuery = getForeignKeyQuery(obj, cld, cds);
}
}
}
Then in my app I would write something like this:
class gov.doi.cap.ojb.query.BuildProjectsQuery
implements QueryBuilder { ... }
collection-descriptor
name=projects
elementClass=gov.doi.cap.ojb.dataobjects.Project
...
query class=gov.doi.cap.ojb.query.BuildProjectsQuery
attribute
attribute-name=earliestStart
attribute-value=1999
/
attribute
attribute-name=latestStart
attribute-value=2001
/
/query
/collection-descriptor
This would allow great flexibility in the specification of the collection
contents, without requiring a query syntax to be defined in XML.
-steve
Steve Clark
Technology Applications Team
Natural
Resources Research Center/USGS
[EMAIL PROTECTED]
(970)226-9291
Date: Fri, 21 Feb 2003 17:49:32 +0100
From: Jakob Braeuchi [EMAIL PROTECTED]
To: OJB Users List [EMAIL PROTECTED]
Subject: Re: 1:M querys constraints
hi bill,
what kind of restrictions woukd you need in the collection-descriptor ?
do we need the full blown criteria there ?
have you already any ideas
about the definition of these restrictions ?
i'm asking these questions because i do not want to parse restrictions
in the collection-descriptor.
i prefer a simpler solution like :
restriction
field=firstname operation== value=Mark /
restriction field=lastname operation=like value=M% /
how could we handle 'AND' / 'OR' ?
what do yout think about ?
jakob
-
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]
Re: 1:M querys constraints
Bill,
It looks like you didn't send this to the list, only to me.
I wanted to clarify a couple of things, especially where you thought that my
approach would require extensive metadata mods. My intention is that the only
addition would be the query element, which has a 'class' attribute and then
the existing custom attribute tag. Knowledge of hard coded values,
child/parent references, AND/OR, etc. would be in the concrete Builder
implementation class itself - Java is a much better language than XML to express
this kind of stuff.
So, looking at my example, the BuildProjectsQuery would know its job is to add a
couple of criteria to handle the requested date range. The Builder would in
this case be specific to a particular relationship. A given Builder
implementation would document the specific attribute names (which really are
parameters, as you wrote) which it expected to find in its CollectionDescriptor.
As far as being overkill for a simple restriction, I was thinking that OJB would
eventually ship with a number of basic Builders - NonFKCollectionQueryBuilder,
ConstantFieldQueryBuilder, DateRangeQueryBuilder, etc. That way we get the best
of both worlds - simple end-user specification of simple restrictions, and lots
of flexibility for those who need it.
-steve
Date: Fri, 21 Feb 2003 10:13:30 -0800 (GMT-08:00)
From: V B Skrypnyk [EMAIL PROTECTED]
To: sclark [EMAIL PROTECTED]
Subject: Re: 1:M querys constraints
Hi,
I would agree with Steve's approach. I think it would require fairly
extensive configuration addition to metadata to support all
possible types of restrictions, as they can reference hard coded
values, as well as references to child and/or parent fields
(with appended hard coded tokens like '%' for like restrictions),
as well as AND / OR, etc.
On the other hand, having a wholly custom query defined for
a collection may be an overkill for a simple restriction. Perhaps,
it may simplify matters, if there is a provision for a callback class
that would modify a naturally existing association, like so:
collection-descriptor
name=projects
elementClass=gov.doi.cap.ojb.dataobjects.Project
..
constraint class=my.custom.query.restrictor
parameter key=key1 value=value1/
parameter key=key2 value=value2/
/constraint
/collection-descriptor
The query restrictor would get an access to the already existing
Query and can add or remove terms from it.
In any case, there is still an issue of how to pass dynamic
parameters for query restriction at runtime. Any other options besides metadata
manipulation?
It would be nice to do something like this:
Engineer e = get engineer from data store
e.setProjectCollectionConstraints( firstDate, secondDate );
Iterator it = e.getProjects();
while( it.hasNext() ) {
...
}
In this case the restrictor callback or query builder would have
to have an access to the instance of the object that 'originates'
the query. Any ideas?
--Bill.
Here's an idea on the collection restriction discussion. How about something
like this:
/**
* Interface implemented by classes which are used to create a custom
* query for the contents of a
collection property, when the usual
* fk/pk approach is insufficient.
*/
interface org.apache.ojb.broker.query.QueryBuilder
/** Build the query to retrieve the specified collection property
*/
Query buildQuery(Object obj, ClassDescriptor cld, CollectionDescriptor
cds);
}
class PersistenceBrokerImpl {
private void retrieveCollection(...) {
if (cds.getQueryBuilder()
!= null)
{
fkQuery = cds.getQueryBuilder.buildQuery(obj, cld, cls);
}
else if (cds.isMtoNRelation())
{
fkQuery = getMtoNQuery(obj, cld, cds);
}
else
{
fkQuery = getForeignKeyQuery(obj, cld, cds);
}
}
}
Then in my app I would write something like this:
class gov.doi.cap.ojb.query.BuildProjectsQuery
implements QueryBuilder { ... }
collection-descriptor
name=projects
elementClass=gov.doi.cap.ojb.dataobjects.Project
...
query class=gov.doi.cap.ojb.query.BuildProjectsQuery
attribute
attribute-name=earliestStart
attribute-value=1999
/
attribute
attribute-name=latestStart
attribute-value=2001
/
/query
/collection-descriptor
This would allow great flexibility in the specification of the collection
contents, without requiring a query syntax to be defined in XML.
-steve
Steve Clark
Technology Applications Team
Natural
Resources Research Center/USGS
[EMAIL PROTECTED]
(970)226-9291
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: 1:M querys constraints
Hi Steve,
It looks like you didn't send this to the list, only to me.
Sorry, email client woes :((
I wanted to clarify a couple of things, especially where you thought that
my
approach would require extensive metadata mods. My intention is that the
only
addition would be the query element, which has a 'class' attribute and
then
the existing custom attribute tag. Knowledge of hard coded values,
child/parent references, AND/OR, etc. would be in the concrete Builder
implementation class itself - Java is a much better language than XML to
express
this kind of stuff.
I was referring to Jacob's suggestion -- yours doesn't require any major
metadata
extensions.
So, looking at my example, the BuildProjectsQuery would know its job is to
add a
couple of criteria to handle the requested date range. The Builder would
in
this case be specific to a particular relationship. A given Builder
implementation would document the specific attribute names (which really
are
parameters, as you wrote) which it expected to find in its
CollectionDescriptor.
Still, how would you address dynamic parameters to your restricted queries.
Your date range is a perfect example. I imagine you may want to change this
range at runtime. Would you have to modify the metadata at runtime as well.
Doing it this way seems a little scary, because you are then responsible for
restoring the previous state if you don't want the changes to persist (even
in the same thread).
As far as being overkill for a simple restriction, I was thinking that OJB
would
eventually ship with a number of basic Builders -
NonFKCollectionQueryBuilder,
ConstantFieldQueryBuilder, DateRangeQueryBuilder, etc. That way we get
the best
of both worlds - simple end-user specification of simple restrictions, and
lots
of flexibility for those who need it.
The reason why I suggested to do a callback was because from the user
perspective I am ignorant of the way that the association between the
objects is constructed -- I am only interested in restricting that
association. So if a collection descriptor specifies an M:N relationship or
1:N relationship I felt it would be a duplication of an already existing
mechanism to replicate logic how to construct these queries in a custom
query builder, if I only need to restrict it. Perhaps, one may argue that
you also have to know enough about the query to be able to modify it in the
callback...
Regards,
--Bill
-steve
Date: Fri, 21 Feb 2003 10:13:30 -0800 (GMT-08:00)
From: V B Skrypnyk [EMAIL PROTECTED]
To: sclark [EMAIL PROTECTED]
Subject: Re: 1:M querys constraints
Hi,
I would agree with Steve's approach. I think it would require fairly
extensive configuration addition to metadata to support all
possible types of restrictions, as they can reference hard coded
values, as well as references to child and/or parent fields
(with appended hard coded tokens like '%' for like restrictions),
as well as AND / OR, etc.
On the other hand, having a wholly custom query defined for
a collection may be an overkill for a simple restriction. Perhaps,
it may simplify matters, if there is a provision for a callback class
that would modify a naturally existing association, like so:
collection-descriptor
name=projects
elementClass=gov.doi.cap.ojb.dataobjects.Project
..
constraint class=my.custom.query.restrictor
parameter key=key1 value=value1/
parameter key=key2 value=value2/
/constraint
/collection-descriptor
The query restrictor would get an access to the already existing
Query and can add or remove terms from it.
In any case, there is still an issue of how to pass dynamic
parameters for query restriction at runtime. Any other options besides
metadata
manipulation?
It would be nice to do something like this:
Engineer e = get engineer from data store
e.setProjectCollectionConstraints( firstDate, secondDate );
Iterator it = e.getProjects();
while( it.hasNext() ) {
...
}
In this case the restrictor callback or query builder would have
to have an access to the instance of the object that 'originates'
the query. Any ideas?
--Bill.
Here's an idea on the collection restriction discussion. How about
something
like this:
/**
* Interface implemented by classes which are used to create a custom
* query for the contents of a
collection property, when the usual
* fk/pk approach is insufficient.
*/
interface org.apache.ojb.broker.query.QueryBuilder
/** Build the query to retrieve the specified collection property
*/
Query buildQuery(Object obj, ClassDescriptor cld,
CollectionDescriptor
cds);
}
class PersistenceBrokerImpl {
private void retrieveCollection(...) {
if (cds.getQueryBuilder()
!= null)
{
fkQuery = cds.getQueryBuilder.buildQuery(obj, cld, cls);
}
else if (cds.isMtoNRelation())
{
fkQuery = getMtoNQuery(obj, cld, cds
RE: 1:M querys constraints
I tried what you suggested and I didn't get the results I want. Let me explain my problem a little more. I have a Person class: class-descriptor class=com.wingate.us.db.Person table=people field-descriptor name=ID column=person_id jdbc-type=BIGINT primarykey=true autoincrement=true / field-descriptor name=firstName column=firstname jdbc-type=VARCHAR nullable=false / ... collection-descriptor name=timeSheetDays element-class-ref=com.wingate.us.db.TimeSheetDay orderby=workDate sort=DESC auto-retrieve=true inverse-foreignkey field-ref=personID/ /collection-descriptor /class-descriptor And a TimeSheetDay class class-descriptor class=com.wingate.us.db.TimeSheetDay table=timeSheetDays field-descriptor name=ID column=timeSheet_id jdbc-type=BIGINT primarykey=true autoincrement=true / field-descriptor name=personID column=person_id jdbc-type=BIGINT / ... field-descriptor name=workDate column=work_date jdbc-type=TIMESTAMP nullable=false/ reference-descriptor name=person class-ref=com.wingate.us.db.Person foreignkey field-ref=personID/ /reference-descriptor ... /class-descriptor This should define a 1:M relationship between Person and TimeSheetDays and a 1:1 relationship between TimeSheetDays and Person. If I do a query like: Criteria crit = new Criteria(); crit.addBetween(timeSheetDays.workDate, startDate, endDate); Query q = QueryFactory.newQuery(Person.class, crit, true); Collection results = _pb.getCollectionByQuery(q); I get back a list of Person objects who have TimeSheetDays between the startDate and endDate. That is ok, but the TimeSheetDays collection (inside of each Person object) contains all TimeSheetDays for that Person. What I want is for TimeSheetDays collection (inside of the Person object) to contain only those TimeSheetDay objects that fall between the startDate and endDate. If I execute a query like (which is what I think you suggested): Criteria crit = new Criteria(); crit.addBetween(workDate, startDate, endDate); Query q = QueryFactory.newQuery(TimeSheetDay.class, crit, true); Collection results = _pb.getCollectionByQuery(q); I get back a list of TimeSheetDay ojbects that fall between the startDate and endDate. But what I want is the inverse of this (as explained above). Does that make sense? Like I mentioned, I can see how I could do this manually: Query for the list of people and then for each person do another query for the right TimeSheetDays collection and then manually set that collection in each person. But I would think OJB could handle this for me if I could just set up the query correctly. Is there a slick way to handle this? -Jason -Original Message- From: Robert S. Sfeir [mailto:[EMAIL PROTECTED]] Sent: Tuesday, February 18, 2003 7:01 PM To: OJB Users List Subject: Re: 1:M querys constraints relate the day class to people, then do the search on the day class date range, and set auto-retrieve=true it should populate everything in one Collection. On Tuesday, Feb 18, 2003, at 19:11 US/Eastern, Jason Hale wrote: I am looking for the best way to handle the following situation: Let's say I have a 1:M relationship between a person and day class. I would like to execute a query that would give me back all the people but constraint the list of day objects for each person. Something like, give me all people, but only populate my days collection with days between 2/1/2003 and 2/15/2003 I can get this to work by retrieving all the people and then for each person execute a query that returns my constrained day collection and then manually setting that collection on the person object. But this does not seem optimal. Any suggestions? -Jason - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] R -- Robert S. Sfeir Senior Java Engineer National Institutes of Health Center for Information Technology Department of Enterprise Custom Applications [EMAIL PROTECTED] - 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]
Re: 1:M querys constraints
On Wednesday, Feb 19, 2003, at 12:37 US/Eastern, Jason Hale wrote:
reference-descriptor name=person
class-ref=com.wingate.us.db.Person
foreignkey field-ref=personID/
/reference-descriptor
First thing I noticed is that you don't have auto-retrieve=true here.
Second you're using PersistenceBroker and I'm not, I'm using ODMG.
here is my full code for the XML and the pertinent method:
class-descriptor class=com.lawton.business.HomeBO table=HOMES
field-descriptor name=homeID column=homeID jdbc-type=INTEGER
autoincrement=true primarykey=true nullable=false/
field-descriptor name=status column=status jdbc-type=VARCHAR
nullable=false/
field-descriptor name=description column=description
jdbc-type=VARCHAR nullable=true/
field-descriptor name=createDate column=createDate
jdbc-type=TIMESTAMP nullable=false/
field-descriptor name=updateDate column=updateDate
jdbc-type=TIMESTAMP nullable=false/
field-descriptor name=name column=name jdbc-type=VARCHAR
nullable=true/
field-descriptor name=title column=title jdbc-type=VARCHAR
nullable=true/
field-descriptor name=moreInfo column=moreInfo
jdbc-type=VARCHAR nullable=true/
field-descriptor name=price column=price jdbc-type=DOUBLE
nullable=true/
field-descriptor name=sqFootage column=sqFootage
jdbc-type=INTEGER nullable=true/
field-descriptor name=featured column=isFeatured
jdbc-type=VARCHAR nullable=true/
field-descriptor name=ownerLetter column=ownerLetter
jdbc-type=VARCHAR nullable=true/
field-descriptor name=onMarketDate column=onMarketDate
jdbc-type=DATE nullable=true/
field-descriptor name=featuredStartDate column=featuredStartDate
jdbc-type=DATE nullable=true/
field-descriptor name=featuredEndDate column=featuredEndDate
jdbc-type=DATE nullable=true/
field-descriptor name=offerDate column=offerDate jdbc-type=DATE
nullable=true/
field-descriptor name=MLS column=mls jdbc-type=VARCHAR
nullable=true/
collection-descriptor
element-class-ref=com.lawton.business.BrokersToHomesBO
name=brokerHomesColl auto-retrieve=true
inverse-foreignkey field-ref=homeID/
/collection-descriptor
collection-descriptor
element-class-ref=com.lawton.business.AgentsToHomesBO
name=agentHomesColl auto-retrieve=true
inverse-foreignkey field-ref=homeID/
/collection-descriptor
collection-descriptor
element-class-ref=com.lawton.business.AmenitiesBO name=amenityColl
auto-retrieve=true
inverse-foreignkey field-ref=homeID/
/collection-descriptor
collection-descriptor
element-class-ref=com.lawton.business.DisclosureBO
name=disclosureColl auto-retrieve=true
inverse-foreignkey field-ref=homeID/
/collection-descriptor
collection-descriptor element-class-ref=com.lawton.business.RoomBO
name=roomColl auto-retrieve=true
inverse-foreignkey field-ref=homeID/
/collection-descriptor
collection-descriptor
element-class-ref=com.lawton.business.VisitScheduleBO
name=visitColl auto-retrieve=true
inverse-foreignkey field-ref=homeID/
/collection-descriptor
/class-descriptor
class-descriptor class=com.lawton.business.BrokersToHomesBO
table=BROKERS_TO_HOMES
field-descriptor name=recordID column=recordID
jdbc-type=INTEGER primarykey=true autoincrement=true/
field-descriptor name=brokerID column=brokerID
jdbc-type=INTEGER nullable=false/
field-descriptor name=homeID column=homeID jdbc-type=INTEGER
nullable=false/
reference-descriptor name=brokerBO
class-ref=com.lawton.business.BrokerBO auto-retrieve=true
foreignkey field-ref=brokerID/
/reference-descriptor
reference-descriptor name=homeBO
class-ref=com.lawton.business.HomeBO auto-retrieve=true
foreignkey field-ref=homeID/
/reference-descriptor
/class-descriptor
class-descriptor class=com.lawton.business.AgentsToHomesBO
table=AGENTS_TO_HOMES
field-descriptor name=recordID column=recordID
jdbc-type=INTEGER primarykey=true autoincrement=true/
field-descriptor name=agentID column=agentID jdbc-type=INTEGER
nullable=false/
field-descriptor name=homeID column=homeID jdbc-type=INTEGER
nullable=false/
reference-descriptor name=agentBO
class-ref=com.lawton.business.AgentBO auto-retrieve=true
foreignkey field-ref=agentID/
/reference-descriptor
reference-descriptor name=homeBO
class-ref=com.lawton.business.HomeBO auto-retrieve=true
foreignkey field-ref=homeID/
/reference-descriptor
/class-descriptor
public HomeDetailView selectHomeDetail( Integer homeID ) throws
DataAccessException
{
List results = null;
HomeBO home = null;
HomeDetailView homeDet = null;
Transaction tx = null;
try
{
tx = odmg.newTransaction();
tx.begin();
OQLQuery query = odmg.newOQLQuery();
String sql = select homeDetail from + HomeBO.class.getName();
sql += where homeID = $1;
query.create( sql );
query.bind( homeID );
results = ( List ) query.execute();
tx.commit();
home = ( HomeBO ) results.get( 0 );
homeDet = new HomeDetailView();
homeDet.setBrokerHomesColl( home.getBrokerHomesColl() ); //Returns
one BrokerHomesColl object filled with
RE: 1:M querys constraints
Hello Jason, I think I know where you are coming from -- I had to do a similar thing to enforce security in my object associations. It would REALLY be nice if the associations on objects can be restricted, ie. where FK is treated as 'like' or '' and not '==', etc. I don't know of any **elegant** way of achieving your goal here but you may try to specify your own collection proxy (you probably have to get the latest cvs). At the collection proxy level you can modify the OJB pre-built association query to add additional constaints. The trick is probably to hookup up a preconfigured collection proxy with a set of necessary constraints at runtime into your metadata specification for person object (that's what I meant by not **elegant** :)) I am very interested to know how you end up resolving your problem. Cheers, --Bill. I tried what you suggested and I didn't get the results I want. Let me explain my problem a little more. I have a Person class: class-descriptor class=com.wingate.us.db.Person table=people field-descriptor name=ID column=person_id jdbc-type=BIGINT primarykey=true autoincrement=true / field-descriptor name=firstName column=firstname jdbc-type=VARCHARnullable= false / collection-descriptor name=timeSheetDays element-class-ref=com.wingate.us.db.TimeSheetDay orderby=workDate sort=DESC auto-retrieve=true inverse-foreignkey field-ref=personID/ /collection-descriptor /class-descriptor And a TimeSheetDay class class-descriptor class=com.wingate.us.db.TimeSheetDay table=timeSheetDays field-descriptor name=ID column=timeSheet_id jdbc-type=BIGINT primarykey=true autoincrement=true / field-descriptor name=personID column=person_id jdbc-type=BIGINT / field- descriptor name=workDate column=work_date jdbc-type=TIMESTAMP nullable=false/ reference-descriptor name=person class-ref=com.wingate.us.db.Person foreignkey field- ref=personID/ /reference-descriptor /class-descriptor This should define a 1:M relationship between Person and TimeSheetDays and a 1:1 relationship between TimeSheetDays and Person. If I do a query like: Criteria crit = new Criteria(); crit.addBetween(timeSheetDays.workDate, startDate, endDate); Query q = QueryFactory.newQuery(Person.class, crit, true); Collection results = _pb.getCollectionByQuery(q); I get back a list of Person objects who have TimeSheetDays between the startDate and endDate. That is ok, but the TimeSheetDays collection (inside of each Person object) contains all TimeSheetDays for that Person. What I want is for TimeSheetDays collection (inside of the Person object) to contain only those TimeSheetDay objects that fall between the startDate and endDate. If I execute a query like (which is what I think you suggested): Criteria crit = new Criteria(); crit.addBetween(workDate, startDate, endDate); Query q = QueryFactory. newQuery(TimeSheetDay.class, crit, true); Collection results = _pb.getCollectionByQuery(q); I get back a list of TimeSheetDay ojbects that fall between the startDate and endDate. But what I want is the inverse of this (as explained above). Does that make sense? Like I mentioned, I can see how I could do this manually: Query for the list of people and then for each person do another query for the right TimeSheetDays collection and then manually set that collection in each person. But I would think OJB could handle this for me if I could just set up the query correctly. Is there a slick way to handle this? -Jason -Original Message- From: Robert S. Sfeir [mailto:[EMAIL PROTECTED]] Sent: Tuesday, February 18, 2003 7:01 PM To: OJB Users List Subject: Re: 1:M querys constraints relate the day class to people, then do the search on the day class date range, and set auto-retrieve=true it should populate everything in one Collection. On Tuesday, Feb 18, 2003, at 19:11 US/Eastern, Jason Hale wrote: I am looking for the best way to handle the following situation: Let's say I have a 1:M relationship between a person and day class. I would like to execute a query that would give me back all the people but constraint the list of day objects for each person. Something like, give me all people, but only populate my days collection with days between 2/1/2003 and 2/15/2003 I can get this to work by retrieving all the people and then for each person execute a query that returns my constrained day collection and then manually setting that collection on the person object. But this does not seem optimal. Any suggestions? -Jason - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: ojb- [EMAIL PROTECTED] R -- Robert S. Sfeir Senior Java Engineer National Institutes of Health Center for Information Technology
Re: 1:M querys constraints
hi bill, afaik some time ago i added qualified relationships to the todo list. i just can't find the list in the distribution any more. jakob V B Skrypnyk wrote: Hello Jason, I think I know where you are coming from -- I had to do a similar thing to enforce security in my object associations. It would REALLY be nice if the associations on objects can be restricted, ie. where FK is treated as 'like' or '' and not '==', etc. I don't know of any **elegant** way of achieving your goal here but you may try to specify your own collection proxy (you probably have to get the latest cvs). At the collection proxy level you can modify the OJB pre-built association query to add additional constaints. The trick is probably to hookup up a preconfigured collection proxy with a set of necessary constraints at runtime into your metadata specification for person object (that's what I meant by not **elegant** :)) I am very interested to know how you end up resolving your problem. Cheers, --Bill. I tried what you suggested and I didn't get the results I want. Let me explain my problem a little more. I have a Person class: class-descriptor class=com.wingate.us.db.Person table=people field-descriptor name=ID column=person_id jdbc-type=BIGINT primarykey=true autoincrement=true / field-descriptor name=firstName column=firstname jdbc-type=VARCHAR nullable= false / collection-descriptor name=timeSheetDays element-class-ref=com.wingate.us.db.TimeSheetDay orderby=workDate sort=DESC auto-retrieve=true inverse-foreignkey field-ref=personID/ /collection-descriptor /class-descriptor And a TimeSheetDay class class-descriptor class=com.wingate.us.db.TimeSheetDay table=timeSheetDays field-descriptor name=ID column=timeSheet_id jdbc-type=BIGINT primarykey=true autoincrement=true / field-descriptor name=personID column=person_id jdbc-type=BIGINT / field- descriptor name=workDate column=work_date jdbc-type=TIMESTAMP nullable=false/ reference-descriptor name=person class-ref=com.wingate.us.db.Person foreignkey field- ref=personID/ /reference-descriptor /class-descriptor This should define a 1:M relationship between Person and TimeSheetDays and a 1:1 relationship between TimeSheetDays and Person. If I do a query like: Criteria crit = new Criteria(); crit.addBetween(timeSheetDays.workDate, startDate, endDate); Query q = QueryFactory.newQuery(Person.class, crit, true); Collection results = _pb.getCollectionByQuery(q); I get back a list of Person objects who have TimeSheetDays between the startDate and endDate. That is ok, but the TimeSheetDays collection (inside of each Person object) contains all TimeSheetDays for that Person. What I want is for TimeSheetDays collection (inside of the Person object) to contain only those TimeSheetDay objects that fall between the startDate and endDate. If I execute a query like (which is what I think you suggested): Criteria crit = new Criteria(); crit.addBetween(workDate, startDate, endDate); Query q = QueryFactory. newQuery(TimeSheetDay.class, crit, true); Collection results = _pb.getCollectionByQuery(q); I get back a list of TimeSheetDay ojbects that fall between the startDate and endDate. But what I want is the inverse of this (as explained above). Does that make sense? Like I mentioned, I can see how I could do this manually: Query for the list of people and then for each person do another query for the right TimeSheetDays collection and then manually set that collection in each person. But I would think OJB could handle this for me if I could just set up the query correctly. Is there a slick way to handle this? -Jason -Original Message- From: Robert S. Sfeir [mailto:[EMAIL PROTECTED]] Sent: Tuesday, February 18, 2003 7:01 PM To: OJB Users List Subject: Re: 1:M querys constraints relate the day class to people, then do the search on the day class date range, and set auto-retrieve=true it should populate everything in one Collection. On Tuesday, Feb 18, 2003, at 19:11 US/Eastern, Jason Hale wrote: I am looking for the best way to handle the following situation: Let's say I have a 1:M relationship between a person and day class. I would like to execute a query that would give me back all the people but constraint the list of day objects for each person. Something like, give me all people, but only populate my days collection with days between 2/1/2003 and 2/15/2003 I can get this to work by retrieving all the people and then for each person execute a query that returns my constrained day collection and then manually setting that collection on the person object. But this does not seem optimal. Any suggestions? -Jason - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e
1:M querys constraints
I am looking for the best way to handle the following situation: Let's say I have a 1:M relationship between a person and day class. I would like to execute a query that would give me back all the people but constraint the list of day objects for each person. Something like, give me all people, but only populate my days collection with days between 2/1/2003 and 2/15/2003 I can get this to work by retrieving all the people and then for each person execute a query that returns my constrained day collection and then manually setting that collection on the person object. But this does not seem optimal. Any suggestions? -Jason - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: 1:M querys constraints
relate the day class to people, then do the search on the day class date range, and set auto-retrieve=true it should populate everything in one Collection. On Tuesday, Feb 18, 2003, at 19:11 US/Eastern, Jason Hale wrote: I am looking for the best way to handle the following situation: Let's say I have a 1:M relationship between a person and day class. I would like to execute a query that would give me back all the people but constraint the list of day objects for each person. Something like, give me all people, but only populate my days collection with days between 2/1/2003 and 2/15/2003 I can get this to work by retrieving all the people and then for each person execute a query that returns my constrained day collection and then manually setting that collection on the person object. But this does not seem optimal. Any suggestions? -Jason - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] R -- Robert S. Sfeir Senior Java Engineer National Institutes of Health Center for Information Technology Department of Enterprise Custom Applications [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
