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
