Plans for the future (aka 3.1 roadmap)

[Andrey Razumovsky]

Hello,

I've briefly looked through current JIRAs, mixed it with my own thoughts and
what I recently saw on the mailing lists. I've managed a little list of
features which are desired in Cayenne by me or someone else. Firstly I'd
like to discuss them on dev list, and after that present on users list, so
that they (users) could share their own ideas. The list can contain all
aspects of Cayenne, such as core functionality, GUI support, third-party
integration or some spec compliance. There's no guarantee that any of this
features will appear in Cayenne 3.1, whose development had de-facto started.
But at least we can have in mind other's thoughts and opinions. The list can
appear very messy, but we've not discussed any roadmap recently (in fact,
never since I'm in the project). Of course, there's no assignnee on any of
the tasks, but if there's anyone volunteering whether of the team or not,
please say it :)
Any ideas/critics/comments are greatly welcomed. We can start a new thread
on any specific feature.

So, my list (without any specific order):

Core functionality:
--- Query generics (CAY-1294) - this is largely desired task, but it can
only be done with lots of rework of guts of Cayenne, if ever can in current
architecture. More info in the Jira.

--- Linking Cayenne with some IoC container (more at
http://markmail.org/message/xyyixpaolg45cj4x). in fact, the work had already
started by Andrus.

--- Finish (vertical) inheritance (CAY-1090) - not sure, how much is to be
done there. Link to description is in Jira.

--- Managing DB indexes with Cayenne (CAY-204). This is useful when
forward-engineering, i.e. starting with Cayenne project, then put it in
database (especially many databases).

--- Add support for pre-ordering of relationships (CAY-477) - very useful
feature. Miss it a lot, although never thought about how to implement it.

--- Allowing "lazy" attributes and/or streaming of large data (CAY-316).
Currently Cayenne is quite weak in working with LOBs. For instance, one have
to create separate table for LOBs so that all data is not eagerly fetched in
select query.

--- ROP: add lifecycle callbacks for client classes.

--- ROP: unify client- and server classes. i really want to see classes that
can work both on client and server someday.

GUI support:

--- Create Eclipse plugin for Cayenne.
This is a very large task, somewhat discussed at
http://cayenne.markmail.org/search/?q=eclipse+vs+swing#query:eclipse%20vs%20swing+page:1+mid:3laascxup2afjux5+state:results.

Noone disputes the need of such plugin in general, but we need a leader to
start the project. Personally, I can't do that because of serious lack of
knowledge in SWT.

No matter whether we succeed in creation of plugin or stay with existing
modeler, following points must be improved from our current state:
--- Add some graphical modeling editor for ER and Class diagrams (CAY-762).
Maybe be able to import some existing formats.

--- Stop using HSQL internally in modeling (e.g. switch to JDK preferences).
It is slow and buggy.

--- Improve XML Project <---> code interaction. E.g. generate classes
automatically, generate listener classes and so on.

--- Make GUI tool it more user-friendly (many JIRAs for that, also was a
thread recently, can't find it now). we really can improve user interface
(remove extra clicks, change button positioning etc) and design.


That'll be enough for the first time :)

Thanks,
Andrey

[Michael Gentry]

On Tue, Nov 17, 2009 at 2:26 PM, Andrey Razumovsky
<razumovsky.andrey-***@public.gmane.org> wrote:
> --- ROP: unify client- and server classes. i really want to see classes that
> can work both on client and server someday.

I've never used ROP, but a lot of us here are starting to look into
AJAX for use in our applications and I'm wondering if some kind of
AJAX/JSON support via ROP would be useful.

> GUI support:
>
> ---  Create Eclipse plugin for Cayenne.
> This is a very large task, somewhat discussed at
> http://cayenne.markmail.org/search/?q=eclipse+vs+swing#query:eclipse%20vs%20swing+page:1+mid:3laascxup2afjux5+state:results.
>
> Noone disputes the need of such plugin in general, but we need a leader to
> start the project. Personally, I can't do that because of serious lack of
> knowledge in SWT.

I'm one of those not convinced that making an Eclipse plug-in is the
best course. To me there is very little advantage to doing so, but
that's just my opinion.

> No matter whether we succeed in creation of plugin or stay with existing
> modeler, following points must be improved from our current state:
> --- Add some graphical modeling editor for ER and Class diagrams (CAY-762).
> Maybe be able to import some existing formats.

Generating diagrams has never been high on my list, but I know some
love it. I'm just not sure the path that should be taken to do so.

> --- Stop using HSQL internally in modeling (e.g. switch to JDK preferences).
> It is slow and buggy.

Yes! :-)

> --- Make GUI tool it more user-friendly (many JIRAs for that, also was a
> thread recently, can't find it now). we really can improve user interface
> (remove extra clicks, change button positioning etc) and design.

That was probably the thread I started ... especially the 8/20/2009 12:55pm one:

http://markmail.org/thread/aonhtfa7x3mrez4i

[Evgeny Ryabitskiy]

About Modeler and Cayenne xml configuration:
Maybe we can add some documentation about Cayenne xml configuration format.
To tell people how xml should look like.
I'm prefer to work with xml (I have to... when I need to do merge).
Usually I use modeler only to look what it's generating, to have example :)

About Cayenne Multiple DataDomains:
I tried to use several Caynne DataDomains at same time. So when I use
2 DataDomains, I use 2 DataContexts. First for Oracle and second for
MS SQL. There was a problem with binding to thread DataContext (it can
be only one). I solved it with own ThreadLocal. Second problem was
with Transaction (Except thread binding): Some times JBC Driver for
Node is resolved from Transaction. It was really crazy for me when my
DataDomain configured on Oracle tried to use JTDS Driver and Microsoft
templates for Oracle DB. It was like a magik! :) I spend whole evening
to find what is happening.

About Cayenne Multiple file configuration:
Cayenne is oriented on only one cayenne.xml. It's painful when you
have several independent modules with own DataMap sets.
I spent enough time to find solution for this. Like experience with
Multiple DataDomains.
It will be nice to have embedded solution for such issues.

About Cayenne and Oracle Timestamp:
Result of query from column of timestamp type was mapped to oracle.sql.TIMESTAMP
I should tell you that we are trying to build cross-rdbms application
via cayenne.
So we didn't expect any non-jdbc types in results.

About Cayenne Queries:
Just a fillings... Sometimes use of query API is really painful...
I have some ideas for enchantments in mind... When I finish to
formulate them, I publish them.

Evgeny.

P.S. Thx for electing me as a contributor :)


2009/11/17 Michael Gentry <mgentry-VS7hab3+SuYeIZ0/***@public.gmane.org>:
> On Tue, Nov 17, 2009 at 2:26 PM, Andrey Razumovsky
> <razumovsky.andrey-***@public.gmane.org> wrote:
>> --- ROP: unify client- and server classes. i really want to see classes that
>> can work both on client and server someday.
>
> I've never used ROP, but a lot of us here are starting to look into
> AJAX for use in our applications and I'm wondering if some kind of
> AJAX/JSON support via ROP would be useful.
>
>> GUI support:
>>
>> ---  Create Eclipse plugin for Cayenne.
>> This is a very large task, somewhat discussed at
>> http://cayenne.markmail.org/search/?q=eclipse+vs+swing#query:eclipse%20vs%20swing+page:1+mid:3laascxup2afjux5+state:results.
>>
>> Noone disputes the need of such plugin in general, but we need a leader to
>> start the project. Personally, I can't do that because of serious lack of
>> knowledge in SWT.
>
> I'm one of those not convinced that making an Eclipse plug-in is the
> best course.  To me there is very little advantage to doing so, but
> that's just my opinion.
>
>> No matter whether we succeed in creation of plugin or stay with existing
>> modeler, following points must be improved from our current state:
>> --- Add some graphical modeling editor for ER and Class diagrams (CAY-762).
>> Maybe be able to import some existing formats.
>
> Generating diagrams has never been high on my list, but I know some
> love it.  I'm just not sure the path that should be taken to do so.
>
>> --- Stop using HSQL internally in modeling (e.g. switch to JDK preferences).
>> It is slow and buggy.
>
> Yes!  :-)
>
>> --- Make GUI tool it more user-friendly (many JIRAs for that, also was a
>> thread recently, can't find it now). we really can improve user interface
>> (remove extra clicks, change button positioning etc) and design.
>
> That was probably the thread I started ... especially the 8/20/2009 12:55pm one:
>
> http://markmail.org/thread/aonhtfa7x3mrez4i
>

[Malcolm Edgar]

Hi All,

My 2 cents worth.

I would love to see Cayenne add support for indexes and constraints,
as it manages our physical database model.

I would also like to see a diagramming tool for creating models. I
think this would be a killer feature, but I know this is a pretty
heavy investment and we need to find a good diagramming library and
resolve licensing issues.

I can't see the big payoff for developing a Eclipse plugin, its a lot
of work. However I do know the modeller code base needs an overhaul.

+1 for the Cayenne IoC container, will help configuring the system.

Support for Java UUID primary key generation would be a nice feature as well

regards Malcolm Edgar

On Wed, Nov 18, 2009 at 8:40 AM, Evgeny Ryabitskiy
<evgeny.ryabitskiy-***@public.gmane.org> wrote:
> About Modeler and Cayenne xml configuration:
> Maybe we can add some documentation about Cayenne xml configuration format.
> To tell people how xml should look like.
> I'm prefer to work with xml (I have to... when I need to do merge).
> Usually I use modeler only to look what it's generating, to have example :)
>
> About Cayenne Multiple DataDomains:
>  I tried to use several Caynne DataDomains at same time. So when I use
> 2 DataDomains, I use 2 DataContexts. First for Oracle and second for
> MS SQL. There was a problem with binding to thread DataContext (it can
> be only one). I solved it with own ThreadLocal. Second problem was
> with Transaction (Except thread binding):  Some times JBC Driver for
> Node is resolved from Transaction. It was really crazy for me when my
> DataDomain configured on Oracle tried to use JTDS Driver and Microsoft
> templates for Oracle DB. It was like a magik! :) I spend whole evening
> to find what is happening.
>
> About Cayenne Multiple file configuration:
> Cayenne is oriented on only one cayenne.xml. It's painful when you
> have several independent modules with own DataMap sets.
> I spent enough time to find solution for this. Like experience with
> Multiple DataDomains.
> It will be nice to have embedded solution for such issues.
>
> About Cayenne and Oracle Timestamp:
> Result of query from column of timestamp type was mapped to oracle.sql.TIMESTAMP
> I should tell you that we are trying to build cross-rdbms application
> via cayenne.
> So we didn't expect any non-jdbc types in results.
>
> About Cayenne Queries:
> Just a fillings... Sometimes use of query API is really painful...
> I have some ideas for enchantments in mind... When I finish to
> formulate them, I publish them.
>
>  Evgeny.
>
> P.S. Thx for electing me as a contributor :)
>
>
> 2009/11/17 Michael Gentry <mgentry-VS7hab3+SuYeIZ0/***@public.gmane.org>:
>> On Tue, Nov 17, 2009 at 2:26 PM, Andrey Razumovsky
>> <razumovsky.andrey-***@public.gmane.org> wrote:
>>> --- ROP: unify client- and server classes. i really want to see classes that
>>> can work both on client and server someday.
>>
>> I've never used ROP, but a lot of us here are starting to look into
>> AJAX for use in our applications and I'm wondering if some kind of
>> AJAX/JSON support via ROP would be useful.
>>
>>> GUI support:
>>>
>>> ---  Create Eclipse plugin for Cayenne.
>>> This is a very large task, somewhat discussed at
>>> http://cayenne.markmail.org/search/?q=eclipse+vs+swing#query:eclipse%20vs%20swing+page:1+mid:3laascxup2afjux5+state:results.
>>>
>>> Noone disputes the need of such plugin in general, but we need a leader to
>>> start the project. Personally, I can't do that because of serious lack of
>>> knowledge in SWT.
>>
>> I'm one of those not convinced that making an Eclipse plug-in is the
>> best course.  To me there is very little advantage to doing so, but
>> that's just my opinion.
>>
>>> No matter whether we succeed in creation of plugin or stay with existing
>>> modeler, following points must be improved from our current state:
>>> --- Add some graphical modeling editor for ER and Class diagrams (CAY-762).
>>> Maybe be able to import some existing formats.
>>
>> Generating diagrams has never been high on my list, but I know some
>> love it.  I'm just not sure the path that should be taken to do so.
>>
>>> --- Stop using HSQL internally in modeling (e.g. switch to JDK preferences).
>>> It is slow and buggy.
>>
>> Yes!  :-)
>>
>>> --- Make GUI tool it more user-friendly (many JIRAs for that, also was a
>>> thread recently, can't find it now). we really can improve user interface
>>> (remove extra clicks, change button positioning etc) and design.
>>
>> That was probably the thread I started ... especially the 8/20/2009 12:55pm one:
>>
>> http://markmail.org/thread/aonhtfa7x3mrez4i
>>
>

[Aristedes Maniatis]

On 18/11/09 8:40 AM, Evgeny Ryabitskiy wrote:
> Maybe we can add some documentation about Cayenne xml configuration format.
> To tell people how xml should look like.

http://cayenne.apache.org/schema/3.0/modelMap.html

Ari


--

-------------------------->
Aristedes Maniatis
GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A

[Kevin Menard]

On Tue, Nov 17, 2009 at 2:53 PM, Michael Gentry <mgentry-VS7hab3+SuYeIZ0/***@public.gmane.org> wrote:
> On Tue, Nov 17, 2009 at 2:26 PM, Andrey Razumovsky
> <razumovsky.andrey-***@public.gmane.org> wrote:
>> --- ROP: unify client- and server classes. i really want to see classes that
>> can work both on client and server someday.
>
> I've never used ROP, but a lot of us here are starting to look into
> AJAX for use in our applications and I'm wondering if some kind of
> AJAX/JSON support via ROP would be useful.

We had an SoC project a few summers back that support WSDL for ROP.
That may be your best bet and it is something I'd like to resurrect.
Layering JSON on top of that should be rather straightforward.

--
Kevin

[Andrey Razumovsky]

I really want to have some "ROP AJAX client" too. Particularily, GWT ROP
CLient, so that we could work on Web client same way (but using async calls,
of course) we do it on ROP client. What I soon found is that currently ROP
client has very complicated logic, in fact it lives its own life. E.g. it
can do resolving lazy relationships as needed (and in the middle of
method!), which is impossible in asynchronous AJAX model. So I ended up
writing simple module that converts server-side objects to JSON.
Another problem is that unlike server-side objects, client-side objects do
not have a map for all properties (anyone knows why it was done so?),
therefore they cannot be resolved without Reflection, and GWT does not have
reflection. But, I really want to fix this in 3.1 as a step to unificate
server-side and client-side objects.
So, creating "GWT ROP Client" is a separate step, which contains several
ideas from ROP, but should have its own architecture.

2009/11/19 Kevin Menard <nirvdrum-***@public.gmane.org>

> On Tue, Nov 17, 2009 at 2:53 PM, Michael Gentry <mgentry-VS7hab3+SuYeIZ0/***@public.gmane.org>
> wrote:
> > On Tue, Nov 17, 2009 at 2:26 PM, Andrey Razumovsky
> > <razumovsky.andrey-***@public.gmane.org> wrote:
> >> --- ROP: unify client- and server classes. i really want to see classes
> that
> >> can work both on client and server someday.
> >
> > I've never used ROP, but a lot of us here are starting to look into
> > AJAX for use in our applications and I'm wondering if some kind of
> > AJAX/JSON support via ROP would be useful.
>
> We had an SoC project a few summers back that support WSDL for ROP.
> That may be your best bet and it is something I'd like to resurrect.
> Layering JSON on top of that should be rather straightforward.
>
> --
> Kevin
>



--
Andrey

[Andrus Adamchik]

Exactly my thoughts. ROP is trying to provide all possible query
types, and close to 100% of Cayenne server functionality on the
client. This won't map well to a JS client. A different simpler
protocol is needed.

> Another problem is that unlike server-side objects, client-side
> objects do
> not have a map for all properties (anyone knows why it was done so?),
> therefore they cannot be resolved without Reflection, and GWT does
> not have
> reflection.


We wanted lighter POJO on the client.

Andrus

On Nov 19, 2009, at 10:21 AM, Andrey Razumovsky wrote:

> I really want to have some "ROP AJAX client" too. Particularily, GWT
> ROP
> CLient, so that we could work on Web client same way (but using
> async calls,
> of course) we do it on ROP client. What I soon found is that
> currently ROP
> client has very complicated logic, in fact it lives its own life.
> E.g. it
> can do resolving lazy relationships as needed (and in the middle of
> method!), which is impossible in asynchronous AJAX model. So I ended
> up
> writing simple module that converts server-side objects to JSON.
> Another problem is that unlike server-side objects, client-side
> objects do
> not have a map for all properties (anyone knows why it was done so?),
> therefore they cannot be resolved without Reflection, and GWT does
> not have
> reflection. But, I really want to fix this in 3.1 as a step to
> unificate
> server-side and client-side objects.
> So, creating "GWT ROP Client" is a separate step, which contains
> several
> ideas from ROP, but should have its own architecture.

[Tore Halset]

Hello.

I fully agree. When I worked on the cocoa ROP client, I had to
recreate a lot of cayenne classes to be able to talk ROP.

One ugly example is ObjectId. As you know, ObjectId has an internal
optimization that uses a single key/value for single column primary
key and a Map for multi column primary key. Even this detail is
exposed on the wire and must be implemented by the client.

- Tore.

On Nov 19, 2009, at 9:36 , Andrus Adamchik wrote:

> Exactly my thoughts. ROP is trying to provide all possible query
> types, and close to 100% of Cayenne server functionality on the
> client. This won't map well to a JS client. A different simpler
> protocol is needed.
>
>> Another problem is that unlike server-side objects, client-side
>> objects do
>> not have a map for all properties (anyone knows why it was done so?),
>> therefore they cannot be resolved without Reflection, and GWT does
>> not have
>> reflection.
>
>
> We wanted lighter POJO on the client.
>
> Andrus
>
> On Nov 19, 2009, at 10:21 AM, Andrey Razumovsky wrote:
>
>> I really want to have some "ROP AJAX client" too. Particularily,
>> GWT ROP
>> CLient, so that we could work on Web client same way (but using
>> async calls,
>> of course) we do it on ROP client. What I soon found is that
>> currently ROP
>> client has very complicated logic, in fact it lives its own life.
>> E.g. it
>> can do resolving lazy relationships as needed (and in the middle of
>> method!), which is impossible in asynchronous AJAX model. So I
>> ended up
>> writing simple module that converts server-side objects to JSON.
>> Another problem is that unlike server-side objects, client-side
>> objects do
>> not have a map for all properties (anyone knows why it was done so?),
>> therefore they cannot be resolved without Reflection, and GWT does
>> not have
>> reflection. But, I really want to fix this in 3.1 as a step to
>> unificate
>> server-side and client-side objects.
>> So, creating "GWT ROP Client" is a separate step, which contains
>> several
>> ideas from ROP, but should have its own architecture.
>
>

[Andrey Razumovsky]

>
> We wanted lighter POJO on the client.
>
>
Are you sure serialization speed/size for Hessian/java serialization will be
better for class with 10 attributes than class with one HashMap attribute,
*probably* containing those attributes? (and why?)

[Andrus Adamchik]

Actually with Hessian it may be only marginally larger with HashMap
(IIRC how it does map serialization). With Java serialization it will
be significantly larger, as it likely serializes all the hash bucket
structure.

In any event, like I said in another thread, if we are to reconcile
the object structures between ROP and regular Cayenne, I'd rather we
move closer to POJO instead of away from it (with important exception
being support for generic objects). POJO's take less memory, have no
threading issues and are generally easier to understand by the users.

Andrus


On Nov 19, 2009, at 11:10 AM, Andrey Razumovsky wrote:
>> We wanted lighter POJO on the client.
>>
>>
> Are you sure serialization speed/size for Hessian/java serialization
> will be
> better for class with 10 attributes than class with one HashMap
> attribute,
> *probably* containing those attributes? (and why?)

[Andrey Razumovsky]

So you suggest to use simple fields as properties? Makes sense. We could
stay in same DataObject interface as now. Then read/writeProperty methods
would work through reflection.. I agree this will make classes more
POJO-like

2009/11/19 Andrus Adamchik <andrus-***@public.gmane.org>

> Actually with Hessian it may be only marginally larger with HashMap (IIRC
> how it does map serialization). With Java serialization it will be
> significantly larger, as it likely serializes all the hash bucket structure.
>
> In any event, like I said in another thread, if we are to reconcile the
> object structures between ROP and regular Cayenne, I'd rather we move closer
> to POJO instead of away from it (with important exception being support for
> generic objects). POJO's take less memory, have no threading issues and are
> generally easier to understand by the users.
>
> Andrus
>
>
>
> On Nov 19, 2009, at 11:10 AM, Andrey Razumovsky wrote:
>
>> We wanted lighter POJO on the client.
>>>
>>>
>>> Are you sure serialization speed/size for Hessian/java serialization
>> will be
>> better for class with 10 attributes than class with one HashMap attribute,
>> *probably* containing those attributes? (and why?)
>>
>
>


--
Andrey

[Andrus Adamchik]

Yeah, something like that. Also Cayenne's own object access since 3.0
is fully based on pluggable ClassDescriptors, so declaring read/
writeProperty on the object is not needed for Cayenne, and technically
only the generic objects need such user-facing methods.

Andrus


On Nov 19, 2009, at 12:26 PM, Andrey Razumovsky wrote:

> So you suggest to use simple fields as properties? Makes sense. We
> could
> stay in same DataObject interface as now. Then read/writeProperty
> methods
> would work through reflection.. I agree this will make classes more
> POJO-like
>
> 2009/11/19 Andrus Adamchik <andrus-***@public.gmane.org>
>
>> Actually with Hessian it may be only marginally larger with HashMap
>> (IIRC
>> how it does map serialization). With Java serialization it will be
>> significantly larger, as it likely serializes all the hash bucket
>> structure.
>>
>> In any event, like I said in another thread, if we are to reconcile
>> the
>> object structures between ROP and regular Cayenne, I'd rather we
>> move closer
>> to POJO instead of away from it (with important exception being
>> support for
>> generic objects). POJO's take less memory, have no threading issues
>> and are
>> generally easier to understand by the users.
>>
>> Andrus
>>
>>
>>
>> On Nov 19, 2009, at 11:10 AM, Andrey Razumovsky wrote:
>>
>>> We wanted lighter POJO on the client.
>>>>
>>>>
>>>> Are you sure serialization speed/size for Hessian/java
>>>> serialization
>>> will be
>>> better for class with 10 attributes than class with one HashMap
>>> attribute,
>>> *probably* containing those attributes? (and why?)
>>>
>>
>>
>
>
> --
> Andrey

[Andrey Razumovsky]

2009/11/19 Andrus Adamchik <andrus-***@public.gmane.org>

> Also Cayenne's own object access since 3.0 is fully based on pluggable
> ClassDescriptors, so declaring read/writeProperty on the object is not
> needed for Cayenne, and technically only the generic objects need such
> user-facing methods.
>

For that, I'll disagree. I've used DataObject.read/writeProperty a lot in my
code for unified processing of DataObjects (non-generic) and prefer those
method stay in interface (moreover, appear in client-side objects). Vice
versa, read/writeProperty methods should through ClassDescriptors

[Andrus Adamchik]

No question, this can be useful. Where this gets in the way is with
our elusive goal of providing persistence for POJOs without a
framework-mandated superclass.

The good news is that ClassDescriptor design can accommodate any type
of objects (as long as you can force it to use ObjectContext
callbacks). So while it is beneficial to eliminate object structural
gap between ROP and "normal" Cayenne, it looks like support of
separate hierarchies of POJOs (preferably without framework
superclass), and generic objects is in our future (unless we totally
give up on the POJO idea and keep extending CayenneDataObject
everywhere).

Now, if we do support both types of objects across the entire stack,
it will be a user's choice what to inherit from (and as a result
either use read/writeProperty methods or not).

Andrus


On Nov 19, 2009, at 1:12 PM, Andrey Razumovsky wrote:
> 2009/11/19 Andrus Adamchik <andrus-***@public.gmane.org>
>
>> Also Cayenne's own object access since 3.0 is fully based on
>> pluggable
>> ClassDescriptors, so declaring read/writeProperty on the object is
>> not
>> needed for Cayenne, and technically only the generic objects need
>> such
>> user-facing methods.
>>
>
> For that, I'll disagree. I've used DataObject.read/writeProperty a
> lot in my
> code for unified processing of DataObjects (non-generic) and prefer
> those
> method stay in interface (moreover, appear in client-side objects).
> Vice
> versa, read/writeProperty methods should through ClassDescriptors

[Andrey Razumovsky]

OK, lets do this in several steps. The first step would be eliminating
difference between client (PersistentObject) and server (CDO). This also is
part of major goal of eliminating superclass.
In my view this first step is:
1. Moving methods from CDO up to PersistentObject, making PersistentObject
implement DataObject.
2. Eliminating what we can from DO interface ("snapshotVersions"?)
3. Making sure client classes now can act as server classes WITHOUT any
change (i.e. if they extend PersistentObject).
4. Deprecating CDO and start using current client VM's instead of server
ones
After that, we can :
5. remove all usages of DO.read/write Property, add/removeToManyTarget etc
from server code. Ensure DO interface is not used internally. it will make
the only imperative that classes implement Persistent

2009/11/19 Andrus Adamchik <andrus-***@public.gmane.org>

> No question, this can be useful. Where this gets in the way is with our
> elusive goal of providing persistence for POJOs without a framework-mandated
> superclass.
>
> The good news is that ClassDescriptor design can accommodate any type of
> objects (as long as you can force it to use ObjectContext callbacks). So
> while it is beneficial to eliminate object structural gap between ROP and
> "normal" Cayenne, it looks like support of separate hierarchies of POJOs
> (preferably without framework superclass), and generic objects is in our
> future (unless we totally give up on the POJO idea and keep extending
> CayenneDataObject everywhere).
>
> Now, if we do support both types of objects across the entire stack, it
> will be a user's choice what to inherit from (and as a result either use
> read/writeProperty methods or not).
>
> Andrus
>
>
>
> On Nov 19, 2009, at 1:12 PM, Andrey Razumovsky wrote:
>
>> 2009/11/19 Andrus Adamchik <andrus-***@public.gmane.org>
>>
>> Also Cayenne's own object access since 3.0 is fully based on pluggable
>>> ClassDescriptors, so declaring read/writeProperty on the object is not
>>> needed for Cayenne, and technically only the generic objects need such
>>> user-facing methods.
>>>
>>>
>> For that, I'll disagree. I've used DataObject.read/writeProperty a lot in
>> my
>> code for unified processing of DataObjects (non-generic) and prefer those
>> method stay in interface (moreover, appear in client-side objects). Vice
>> versa, read/writeProperty methods should through ClassDescriptors
>>
>
>


--
Andrey

[Andrus Adamchik]

On Nov 19, 2009, at 3:11 PM, Andrey Razumovsky wrote:

> 1. Moving methods from CDO up to PersistentObject, making
> PersistentObject
> implement DataObject.

In fact PO was split from CDO in the past to move it the POJO way (as
well as somewhat coincidentally - the ROP way). I don't want to lose
that work. So I'd say we simply start supporting CDO in ROP and PO on
the server, and let the users decide on their preferred inheritance.

Andrus

[Andrey Razumovsky]

Not exactly. What we need for future use is class "between" PO and CDO. It
should have DO functionality for easy use, but no values stored in hashMap.
In my vision, this class will replace CDO. It is not nessesarily modified PO
class, as I suggested before, but maybe a new class.

2009/11/19 Andrus Adamchik <andrus-***@public.gmane.org>

>
> On Nov 19, 2009, at 3:11 PM, Andrey Razumovsky wrote:
>
> 1. Moving methods from CDO up to PersistentObject, making PersistentObject
>> implement DataObject.
>>
>
> In fact PO was split from CDO in the past to move it the POJO way (as well
> as somewhat coincidentally - the ROP way). I don't want to lose that work.
> So I'd say we simply start supporting CDO in ROP and PO on the server, and
> let the users decide on their preferred inheritance.
>
> Andrus
>
>
>
>


--
Andrey

[Andrus Adamchik]

Then what about generic objects?

http://cayenne.apache.org/doc/generic-persistent-class.html

We may end up with 3 types of objects to support instead of 2:

* Real POJO, no framework mandated superlcass
* CDO POJO (for the lack of a better name)
* CDO generic

Andrus



On Nov 19, 2009, at 3:44 PM, Andrey Razumovsky wrote:

> Not exactly. What we need for future use is class "between" PO and
> CDO. It
> should have DO functionality for easy use, but no values stored in
> hashMap.
> In my vision, this class will replace CDO. It is not nessesarily
> modified PO
> class, as I suggested before, but maybe a new class.
>
> 2009/11/19 Andrus Adamchik <andrus-***@public.gmane.org>
>
>>
>> On Nov 19, 2009, at 3:11 PM, Andrey Razumovsky wrote:
>>
>> 1. Moving methods from CDO up to PersistentObject, making
>> PersistentObject
>>> implement DataObject.
>>>
>>
>> In fact PO was split from CDO in the past to move it the POJO way
>> (as well
>> as somewhat coincidentally - the ROP way). I don't want to lose
>> that work.
>> So I'd say we simply start supporting CDO in ROP and PO on the
>> server, and
>> let the users decide on their preferred inheritance.
>>
>> Andrus
>>
>>
>>
>>
>
>
> --
> Andrey

[Andrus Adamchik]

On Nov 19, 2009, at 3:48 PM, Andrus Adamchik wrote:

> * CDO POJO (for the lack of a better name)
> * CDO generic

Answering my own question... Actually we can probably use the same set
of class descriptors for the above 2 choices... CDO POJO and CDO
generic will use two different superclasses, both implementing the
same (existing) DataObject interface. Cayenne class descriptors will
access both types of objects via that interface.

Andrus

[Andrey Razumovsky]

OK. Let's then just move out to DataObjectUtils (or other helper class)
those read/write generic methods

2009/11/19 Andrus Adamchik <andrus-***@public.gmane.org>

> Then what about generic objects?
>
> http://cayenne.apache.org/doc/generic-persistent-class.html
>
> We may end up with 3 types of objects to support instead of 2:
>
> * Real POJO, no framework mandated superlcass
> * CDO POJO (for the lack of a better name)
> * CDO generic
>
> Andrus
>
>
>
>
> On Nov 19, 2009, at 3:44 PM, Andrey Razumovsky wrote:
>
> Not exactly. What we need for future use is class "between" PO and CDO. It
>> should have DO functionality for easy use, but no values stored in
>> hashMap.
>> In my vision, this class will replace CDO. It is not nessesarily modified
>> PO
>> class, as I suggested before, but maybe a new class.
>>
>> 2009/11/19 Andrus Adamchik <andrus-***@public.gmane.org>
>>
>>
>>> On Nov 19, 2009, at 3:11 PM, Andrey Razumovsky wrote:
>>>
>>> 1. Moving methods from CDO up to PersistentObject, making
>>> PersistentObject
>>>
>>>> implement DataObject.
>>>>
>>>>
>>> In fact PO was split from CDO in the past to move it the POJO way (as
>>> well
>>> as somewhat coincidentally - the ROP way). I don't want to lose that
>>> work.
>>> So I'd say we simply start supporting CDO in ROP and PO on the server,
>>> and
>>> let the users decide on their preferred inheritance.
>>>
>>> Andrus
>>>
>>>
>>>
>>>
>>>
>>
>> --
>> Andrey
>>
>
>


--
Andrey

[Рябицкий Евгений]

One more thing:
I didn't find nice solution for Inserting multiple DataRows in Table.
So I have idea to add BatchInsert operations for API.


-----Original Message-----
From: Andrus Adamchik [mailto:andrus-***@public.gmane.org]
Sent: Thursday, November 19, 2009 4:20 PM
To: dev-***@public.gmane.org
Subject: Re: Plans for the future (aka 3.1 roadmap)


On Nov 19, 2009, at 3:11 PM, Andrey Razumovsky wrote:

> 1. Moving methods from CDO up to PersistentObject, making
> PersistentObject
> implement DataObject.

In fact PO was split from CDO in the past to move it the POJO way (as
well as somewhat coincidentally - the ROP way). I don't want to lose
that work. So I'd say we simply start supporting CDO in ROP and PO on
the server, and let the users decide on their preferred inheritance.

Andrus

[Andrus Adamchik]

On Nov 19, 2009, at 3:47 PM, Рябицкий Евгений wrote:

> One more thing:
> I didn't find nice solution for Inserting multiple DataRows in Table.
> So I have idea to add BatchInsert operations for API.

What about InsertBatchQuery? It is used internally by Cayenne and can
be used by the applications as well.

Andrus

[Рябицкий Евгений]

Yeah. But it's using DBEntity inside to get Table MetaData.
So you should fill up map.xml before. It's painfull...
Idea is to add feature like loading for this DBEntity (as it's done in reverse engineering). + some caching for this DBEntitys.
So user can pass only: TableName, DataMap (even empty), and DataRows.
It will be much easy.



-----Original Message-----
From: Andrus Adamchik [mailto:andrus-***@public.gmane.org]
Sent: Thursday, November 19, 2009 5:01 PM
To: dev-***@public.gmane.org
Subject: Batch inserts


On Nov 19, 2009, at 3:47 PM, Рябицкий Евгений wrote:

> One more thing:
> I didn't find nice solution for Inserting multiple DataRows in Table.
> So I have idea to add BatchInsert operations for API.

What about InsertBatchQuery? It is used internally by Cayenne and can
be used by the applications as well.

Andrus

[Michael Gentry]

On Thu, Nov 19, 2009 at 7:56 AM, Andrus Adamchik <andrus-***@public.gmane.org> wrote:
> No question, this can be useful. Where this gets in the way is with our
> elusive goal of providing persistence for POJOs without a framework-mandated
> superclass.

Maybe I'm just old fashioned, but I actually like inheriting behavior.
I also like being able to step through the code to see what it does.

mrg

[Kevin Menard]

On Thu, Nov 19, 2009 at 9:11 AM, Michael Gentry <mgentry-VS7hab3+SuYeIZ0/***@public.gmane.org> wrote:
> On Thu, Nov 19, 2009 at 7:56 AM, Andrus Adamchik <andrus-***@public.gmane.org> wrote:
>> No question, this can be useful. Where this gets in the way is with our
>> elusive goal of providing persistence for POJOs without a framework-mandated
>> superclass.
>
> Maybe I'm just old fashioned, but I actually like inheriting behavior.
>  I also like being able to step through the code to see what it does.

You're not alone. I found the whole POJO movement set me back a bit.
Debugging dynamically enhanced classes is a major PITA. Having said
that, issues related to multiple inheritance are also annoying. It
could be a lot easier to introduce persistence into an existing
codebase if you don't have to change the class hierarchy.

--
Kevin

[Andrey Razumovsky]

This is all absolutely right, that's why I'm also all for taking the golden
middle in Cayenne, specifically leaving only Persistent interface dependency

2009/11/19 Kevin Menard <nirvdrum-***@public.gmane.org>

> On Thu, Nov 19, 2009 at 9:11 AM, Michael Gentry <mgentry-VS7hab3+SuYeIZ0/***@public.gmane.org>
> wrote:
> > On Thu, Nov 19, 2009 at 7:56 AM, Andrus Adamchik <andrus-***@public.gmane.org>
> wrote:
> >> No question, this can be useful. Where this gets in the way is with our
> >> elusive goal of providing persistence for POJOs without a
> framework-mandated
> >> superclass.
> >
> > Maybe I'm just old fashioned, but I actually like inheriting behavior.
> > I also like being able to step through the code to see what it does.
>
> You're not alone. I found the whole POJO movement set me back a bit.
> Debugging dynamically enhanced classes is a major PITA. Having said
> that, issues related to multiple inheritance are also annoying. It
> could be a lot easier to introduce persistence into an existing
> codebase if you don't have to change the class hierarchy.
>
> --
> Kevin
>



--
Andrey

[Robert Zeigler]

+1.

I've had the "opportunity" lately to work on a largish project (700+
classes, 79 entity classes; over 100 tables result from the mapping)
that is done with hibernate POJO.
To a certain extent, any project with that many entities and tables
can be a pain to manage and work with, but hibernate provides it's own
special level of hell when it comes to debugging.
When things "work", life is great, but when they don't work, I lose
hours trying to figure out what hibernate is doing under the hood.
Recent example was a class cast exception caused by hibernate fetching
an object based on its superclass, but the resulting object was a
hibernate proxy, so a particular assignment, which looked reasonable
and which worked in 90% of the cases, failed (incidentally, in a POJO
model, there are good reasons to use proxies in many situations).
Frankly, I find Cayenne's inheritance model much /easier/ to
understand and debug than hibernate's POJO model. Granted, just
because hibernate's POJO implementation sucks doesn't mean that
cayenne's has to, but I think the POJO bit is mostly* overrated.

Robert

*I have enjoyed Tapestry 5's "POJO" approach to development, but even
there, I enjoy it more as a committer, for the flexibility it affords
in evolving the framework, than as a user. The only real bonus as a
user is that autocomplete works a lot better since the only methods in
the class are the ones I've defined, rather than a bajillion
superclass methods. ;)

On Nov 19, 2009, at 11/198:11 AM , Michael Gentry wrote:

> On Thu, Nov 19, 2009 at 7:56 AM, Andrus Adamchik <andrus-***@public.gmane.org
> > wrote:
>> No question, this can be useful. Where this gets in the way is with
>> our
>> elusive goal of providing persistence for POJOs without a framework-
>> mandated
>> superclass.
>
> Maybe I'm just old fashioned, but I actually like inheriting behavior.
> I also like being able to step through the code to see what it does.
>
> mrg

[Michael Gentry]

Maybe I'm just disagreeable today ... :-)

I like autocomplete, especially as a new user to a framework, showing
me what I can/should override. With T5 I have to hit the
documentation and guess. Do I need setupRender() or pageAttached() or
... With autocomplete, I at least can see a list of methods to help
me get started in that process (and see the JavaDocs for each one to
decide which method to try). And, since the source code is available
if you inherit functionality, you can easily look at it and see
precisely the order things are called. Automagic methods are much
more sealed off.

Thanks,

mrg


On Thu, Nov 19, 2009 at 10:19 AM, Robert Zeigler
<robert.zeigler-jH9kFRQYnY+***@public.gmane.org> wrote:
> *I have enjoyed Tapestry 5's "POJO" approach to development, but even there,
> I enjoy it more as a committer, for the flexibility it affords in evolving
> the framework, than as a user.  The only real bonus as a user is that
> autocomplete works a lot better since the only methods in the class are the
> ones I've defined, rather than a bajillion superclass methods. ;)

[Malcolm Edgar]

Love Roberts POJO comments. I have always found it hypocritical, that
the Hibernate guys managed to kill off JDO, partially using the
argument that JDO use post processing to enhance classes so they are
not pure "POJO". Then Hibernate found out that reflection performance
sucked and switched over to using runtime byte code enhancement. Now
how is that session connected, byte code enhanced subclass a POJO.

I am not saying that the concept of a POJO is bad, but imagine trying
to build a Swing application with POJO's where you had to use
annotations for everything.

regards Malcolm Edgar

On Fri, Nov 20, 2009 at 3:54 AM, Michael Gentry <mgentry-VS7hab3+SuYeIZ0/***@public.gmane.org> wrote:
> Maybe I'm just disagreeable today ... :-)
>
> I like autocomplete, especially as a new user to a framework, showing
> me what I can/should override.  With T5 I have to hit the
> documentation and guess.  Do I need setupRender() or pageAttached() or
> ...  With autocomplete, I at least can see a list of methods to help
> me get started in that process (and see the JavaDocs for each one to
> decide which method to try).  And, since the source code is available
> if you inherit functionality, you can easily look at it and see
> precisely the order things are called.  Automagic methods are much
> more sealed off.
>
> Thanks,
>
> mrg
>
>
> On Thu, Nov 19, 2009 at 10:19 AM, Robert Zeigler
> <robert.zeigler-jH9kFRQYnY+***@public.gmane.org> wrote:
>> *I have enjoyed Tapestry 5's "POJO" approach to development, but even there,
>> I enjoy it more as a committer, for the flexibility it affords in evolving
>> the framework, than as a user.  The only real bonus as a user is that
>> autocomplete works a lot better since the only methods in the class are the
>> ones I've defined, rather than a bajillion superclass methods. ;)
>

[Andrus Adamchik]

I agree with most of the POJO comments in the thread. Since
persistence engine has to do a bunch of tricks throughout the object
lifecycle, it means that POJO is not really a POJO in any ORM. So this
limits the abstraction anyways. At the same time not being able to use
my persistent objects disconnected from context (e.g. to set
relationships), or transfer a subgraph to a Cayenne-unaware client is
annoying as well.

Considering my lack of time and lack of community interest in POJO, I
don't expect an immediate implementation. What I wanted to make sure
though is that we leave the door open for a POJO support with whatever
design we go in 3.1. Aside from a few rough spots, Cayenne is ready to
host POJO class descriptors, and maybe someday they'll materialize
(BTW, we should've dropped experimental version of those from B1. They
are not fully operational, but I guess no harm in them sitting in the
jar).

Also my current concept of Cayenne POJO should not require agent-based
existing class enhancement (using Java agents is more pain than any
user can bare). It will be more like Tapestry, i.e. based on
subclassing rather than redefining a class (not sure if Hibernate does
the same thing? Or some kind of a proxy?):

public class MyObject {
private int persistentField;
...
}

MyObject object = new MyObject();
...
// 'registerObject()' returns a subclass clone of 'object',
// and its relationship subgraph with all the private fields
object = context.registerObject(object);


Andrus