It 70% of all queries:
User u = new User();
u.setLogin("aaaa");
u.setPassword("bbb");
Lits users = db.execute(u);
Or
User u = new User();
u.setLogin("aaaa");
u.setPassword("bbb");
Address a = new Address();
a.setCity("SF");
a.setZip("11111");
u.setAddress(a);
Lits users = db.execute(u);
I think they are better than
"select u from com.company.project.module.User u
where u.login=$1 and u.password=$2"
"select u from com.company.project.module.User u
where u.login=$1 and
u.password=$2 and
u.address.city=$3 and
u.address.zip=$3
"
At least compiler can check existence and type of
field accessors.
Ilia
--- Thomas Yip <[EMAIL PROTECTED]> wrote:
>
>
> I don't think query by example is an item in the
> todo list. It is convenient, no doubt about it.
> Unless many users request it. Even it is, it may
> not be very high in prority.
>
> The functionality of query by example is rather
> limited.
> It doesn't provides enough expression power for
> count(), avg() etc. Not to mention join.
>
> I can add the method for you. However, you
> should aware that the method is not likely to
> be available in the future.
>
>
>
> Thomas
>
> -----Original Message-----
> >From: Ilia Iourovitski [mailto:[EMAIL PROTECTED]]
> >Sent: Monday, April 29, 2002 4:17 PM
> >To: [EMAIL PROTECTED]
> >Subject: Re: [castor-dev] Strategy Proposal (repost
> - was: Castor JDO
> Status)
> >
> >So, can you add this method
> >String FieldMolder::getName()
> >{
> > return _fieldName;
> >}
> >
> >Or maybe you have another idea how to implement
> query
> >by example.
> >
> >Ilia
> >
> >--- Thomas Yip <[EMAIL PROTECTED]> wrote:
> >>
> >>
> >> Well, it is then very different. How much to
> expose
> >> (extenerally) is always trade off flexibility to
> >> make
> >> changes (internally). I am not favor to expose
> more
> >> API, obvious because I am the one who make
> changes.
> >>
> >>
> >>
> >> Thomas
> >>
> >>
> >> -----Original Message-----
> >> >From: Ilia Iourovitski
> [mailto:[EMAIL PROTECTED]]
> >> >Sent: Monday, April 29, 2002 3:16 PM
> >> >To: [EMAIL PROTECTED]
> >> >Subject: Re: [castor-dev] Strategy Proposal
> (repost
> >> - was: Castor JDO
> >> Status)
> >> >
> >> >Thomas
> >> >
> >> >The whole point not about feature requests, but
> >> about
> >> >dividing Castor JDO in peaces which can be
> >> understood
> >> >independently, so developers can add/ modify
> code
> >> in
> >> >timely manner.
> >> >As far as I remember half a year ago I ask you
> to
> >> add
> >> >String FieldMolder::getName() so I can implement
> >> query
> >> >by example. At that time I was told
> >> >that it is a Castor's private class and I
> shouldn't
> >> >touch because it might be change during future
> >> >refactoring.
> >> >Thus the question is which interfaces/classes
> can
> >> be
> >> >accessed freely in order to implement query by
> >> >examples, constraints, SODA API.
> >> >
> >> >
> >> >Modularization in that respect is just
> publishing
> >> >interfaces and their dependencies.
> >> >
> >> >Splitting castor JDO into bunch of components
> >> (Avalon
> >> >style or JMX beans) "might" makes life for
> castor
> >> >users
> >> >ease because every component will implement some
> >> >interface, life cycle, will have configuration
> >> file,
> >> >will publish dependency on other components.
> >> >Particular developer might copy existing
> component
> >> >and simply modify it, and plug it back.
> >> >Right now I think every body has some version of
> >> >Castor
> >> >from cvs with modifications/patches.
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >Thanks
> >> >
> >> >Ilia
> >> >
> >> >Additional comments see below.
> >> >
> >> >
> >> >--- Thomas Yip <[EMAIL PROTECTED]> wrote:
> >> >>
> >> >>
> >> >> I see. You submitted a few feature requests.
> >> >> However, my guess are many of those doesn't
> >> >> really solve by modularization.
> >> >>
> >> >> See below.
> >> >>
> >> >> >> >2. Configuration: support for various
> >> connection
> >> >> >> >pools/
> >> >> >> >containers, ability to construct
> >> >> programmatically
> >> >> >> with
> >> >> >> >user supplied connection, connection to
> the
> >> >> >> multiple
> >> >> >> >databases.
> >> >> >>
> >> >> >> Did you confused package with module?
> >> >> >> Configuration highly depends on how the
> >> >> >> configuration
> >> >> >> be used. How can it be a module of it own.
> I
> >> >> don't
> >> >> >> get it.
> >> >> >
> >> >> >Currently JDO uses database.xml as
> configuration
> >> >> file.
> >> >> >
> >> >> >There is no way to build it programmatically,
> >> i.e
> >> >> >construct DataSource and set it to JDO.
> >> >> >Next there number of JDBC conneciton pools
> which
> >> >> have
> >> >> >different configurations.
> >> >>
> >> >> I think it one is a commonly requested feature
> >> too.
> >> >> It
> >> >> can be added to the request list.
> >> >> However, I don't think split it out helps
> solve
> >> the
> >> >> problem,
> >> >> or encourage parallel development.
> >> >>
> >> >> >But is it possible to use this peace of code.
> >> >>
> >> >> I don't see why you want to use the code that
> >> way.
> >> >>
> >> >> >Database lock (FOR UPDATE) doesn't have
> timeout.
> >> >> >Oracle
> >> >> >provides (FOR UPDATE NO WAIT) but it is not
> used
> >> by
> >> >> >Castor.
> >> >>
> >> >> While what you said is true...
> >> >>
> >> >> >There is no way to try to get lock of object
> >> >> >for given period of programmatically.
> >> >>
> >> >> ... I don't see, again, splitting it out is a
> >> >> solution.
> >> >>
> >> >> >And distributed cashe needs distributed lock.
> >> >>
> >> >> I don't think all distributed cache design
> >> requires
>
=== message truncated ===
__________________________________________________
Do You Yahoo!?
Yahoo! Health - your guide to health and wellness
http://health.yahoo.com
-----------------------------------------------------------
If you wish to unsubscribe from this mailing, send mail to
[EMAIL PROTECTED] with a subject of:
unsubscribe castor-dev
