Hudson build is back to normal: Cayen ne-trunk » JDK 1.5 (latest),HSQLDB #48

See

Re: Accessing object metadata and other utilities

On 24/11/2009, at 11:13 PM, Andrey Razumovsky wrote: > or maybe PersistentUtils +1 makes the most sense (to me at least) given it reflects the flavour of the interface to which these objects belong whether server-side or not. > - because it will work with all types of > classes (or at least tho

Build failed in Hudson: Cayenne-t runk » JDK 1.5 (latest),HSQLDB #47

See Changes: [andrey] deprecating DataObjectUtils and moving its methods to Cayenne [andrey] CAY-1230 Refactoring & unification of "ROP" and "classic" class groups Changing ROP

Re: Nested ROP contexts and relationships

Just committed changes in ROP event processing. In a nutshell, changes are: -removed all ThreadLocals and PropertyChangeProcessingStrategy -removed CCGraphAction & DCGraphAction to the glory of OCGraphAction -added to methods to ToManyProperty -added util.Cayenne class with some internal and extern

Re: Nested ROP contexts and relationships

True, but they are still user facing collections (or more generally valueholders, as this also works for to-one), that get inflated internally as needed. DO faults are singletons of this type: http://cayenne.apache.org/doc/api/org/apache/cayenne/Fault.html So PO lazy relationship resolving g

Re: Nested ROP contexts and relationships

Actually, I don't understand :) PO arc properties are all faults (classes PersistentObject*) 2009/11/24 Andrus Adamchik > > On Nov 24, 2009, at 5:14 PM, Andrey Razumovsky wrote: > > >>> >>> So ... another attempt at abstract analysis (or an attempt at unwinding >>> my >>> memory...) IIRC the mai

Re: Nested ROP contexts and relationships

On Nov 24, 2009, at 5:14 PM, Andrey Razumovsky wrote: So ... another attempt at abstract analysis (or an attempt at unwinding my memory...) IIRC the main difference between DO and PO is fault handling - we can store a Fault instance in a map, but not in a typed ivar. So PO's have no con

Re: Nested ROP contexts and relationships

2009/11/24 Andrus Adamchik > > My question is - why >>> can't we have "silent" addTargetDirectly and removeTargetDirectly for >>> to-many properties? This will allow as to manage event cycles. >>> >> > > I guess we can. This should replace "addReverse" parameter in the > appropriate method. Talk

Re: Nested ROP contexts and relationships

My question is - why can't we have "silent" addTargetDirectly and removeTargetDirectly for to-many properties? This will allow as to manage event cycles. I guess we can. This should replace "addReverse" parameter in the appropriate method. Talking from memory here, I may not remember all

Re: Accessing object metadata and other utilities

I tend to not like abbreviations for the most part (a little peeve of mine -- I fall into the "software is meant to be read, not written" camp), so I'd vote for something more like "Cayenne" in the current org.apache.cayenne.util package. Simple, direct, and to the point. mrg On Tue, Nov 24, 20

Re: Nested ROP contexts and relationships

For POJOs and DO's it can work same as non-silent one, and for ROPs it will differ 2009/11/24 Andrey Razumovsky > Now returning to my main goal - it is to allow PersistentObject subclasses > work correctly on server and cannot be done without changing > PersistentObjectHolder's event procession.

Re: Nested ROP contexts and relationships

Now returning to my main goal - it is to allow PersistentObject subclasses work correctly on server and cannot be done without changing PersistentObjectHolder's event procession. The only reason that we have those PropertyChangeProcessingStrategy and many threadLocals all around is that PersistentO

Re: Accessing object metadata and other utilities

Cayenne or maybe PersistentUtils - because it will work with all types of classes (or at least those that implement Persistent).

Re: Nested ROP contexts and relationships

2009/11/24 Andrus Adamchik > So here is a high-level question - do you think we can use > ClassDescriptor/Property abstraction *internally* to build a unified > ObjectContext implementation for any kind of objects? This was the goal of > the reflect package anyways. > > I think yes. In future :)

Re: Accessing object metadata and other utilities

CayUtils? I'm good with Cayenne, too. Robert On Nov 24, 2009, at 11/245:53 AM , Andrus Adamchik wrote: [As suggested in the parent thread, forking a new thread] On Nov 24, 2009, at 1:41 PM, Robert Zeigler wrote: I'll second that. I ran into a very similar use case yesterday in a hibernate

Accessing object metadata and other utilities

[As suggested in the parent thread, forking a new thread] On Nov 24, 2009, at 1:41 PM, Robert Zeigler wrote: I'll second that. I ran into a very similar use case yesterday in a hibernate project... I was wanting to get at hibernate's version of ClassDescription, and it took me forever to tra

Re: Nested ROP contexts and relationships

So here is a high-level question - do you think we can use ClassDescriptor/Property abstraction *internally* to build a unified ObjectContext implementation for any kind of objects? This was the goal of the reflect package anyways. getEntityResolver ().getClassDescriptor(object.getObjectId

Re: Nested ROP contexts and relationships

On Nov 24, 2009, at 11/245:37 AM , Andrey Razumovsky wrote: 2009/11/24 Andrus Adamchik I did not, but I defined 3 different types of objects (ROP, POJO, JPA) that don't use this approach for setting reverse relationship. So that's what I mean by pluggable :-) And now I want at least

Re: Nested ROP contexts and relationships

2009/11/24 Andrus Adamchik > > I did not, but I defined 3 different types of objects (ROP, POJO, JPA) that > don't use this approach for setting reverse relationship. So that's what I > mean by pluggable :-) > > And now I want at least ROP-like classes do use this approach as well (i mean what is

Re: Nested ROP contexts and relationships

On Nov 24, 2009, at 1:20 PM, Andrey Razumovsky wrote: Have you ever overridden DataObject.setToOneTarget()? I did not, but I defined 3 different types of objects (ROP, POJO, JPA) that don't use this approach for setting reverse relationship. So that's what I mean by pluggable :-) Anyw

Re: Nested ROP contexts and relationships

2009/11/24 Andrus Adamchik > I am ok with this as long as it doesn't break the ability for a to-many > relationship collections to (un)set reverse relationships when regular > collection add/remove methods are called. > > Sure > > 1. Moving DO.addToManyTarget, etc to DataObjectUtils, taking Pe

Re: Nested ROP contexts and relationships

I am ok with this as long as it doesn't break the ability for a to- many relationship collections to (un)set reverse relationships when regular collection add/remove methods are called. 1. Moving DO.addToManyTarget, etc to DataObjectUtils, taking Persistent instead of DO as an argument (act

Re: Nested ROP contexts and relationships

Okay, I've run into same situation when trying to allow PO subclasses in DC, but now I don't see context setting reverse arcs at user's change. The problem is in difference between CC and DC property change processing. Sorry about being so detailed around the code, but I don't see how i can explain