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
>> >> distributed lock. Some does. And, I don't think
>> >> those uses distributed locks suit what castor is
>> >> used for.
>> >>
>> >> If something is implemented and not used right
>> now,
>> >> the chance that it will be used later is very
>> >> unlikely,
>> >> or at least subject to complete rewrite. It is
>> much
>> >> wiser
>> >> to worry it later.
>> >>
>> >> >> >6. Transactions.
>> >> >>
>> >> >> Castor is transaction aware. Castor doesn't
>> not
>> >> >> intent to
>> >> >> be TP monitor. It simply uses transaction. The
>> >> code
>> >> >> definitely can't be spun out.
>> >> >>
>> >> >Currently there is no way to have object id
>> local
>> >> per
>> >> >transaction.
>> >>
>> >> I don't get what you mean. For Castor, the design
>> >> is each transaction have its own objects "view"
>> of
>> >> database. Identity is global.
>> >>
>> >For optimistic transaction you might want to have
>> >identity local and check object version at commit
>> >time.
>> >Castor do support long transaction via unlimited
>> cache
>> >and timestamp, but it is not ideal solution for all
>> >cases
>> >
>> >> I don't see modularize helps, either.
>> >>
>> >>
>> >> Thomas
>> >>
>> >>
>>
>>-----------------------------------------------------------
>> >>
>> >> If you wish to unsubscribe from this mailing,
>> send
>> >> mail to
>> >> [EMAIL PROTECTED] with a subject of:
>> >> unsubscribe castor-dev
>> >>
>> >
>> >__________________________________________________
>> >Do You Yahoo!?
>> >Yahoo! Health - your guide to health and wellness
>> >http://health.yahoo.com
>> >
>>
>=== 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
>
-----------------------------------------------------------
If you wish to unsubscribe from this mailing, send mail to
[EMAIL PROTECTED] with a subject of:
unsubscribe castor-dev
