Mailing-List: contact user-help@cayenne.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@cayenne.apache.org
Received-SPF: pass (athena.apache.org: local policy)
Message-Id: <9AEEEE84-9F51-4E4E-9FFC-C0A8B77CF9B5@objectstyle.org>
From: Andrus Adamchik <andrus@objectstyle.org>
To: user@cayenne.apache.org
In-Reply-To: <cf4fbd7e0903011038q107fd365h9b84af5e147f1bc7@mail.gmail.com>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v930.3)
Subject: Re: First time writer/Design ideas
Date: Mon, 2 Mar 2009 11:44:25 -0500
References: <cf4fbd7e0903011038q107fd365h9b84af5e147f1bc7@mail.gmail.com>

Hi Dave,

Good to see that you liked Cayenne. Some comments in addition to what  
Ari said...


On Mar 1, 2009, at 1:38 PM, Dave Lamy wrote:
> So Question #1:
> What pitfalls/concerns would you voice regarding a completely  
> programmatic
> Configuration/DataMap buildup?  The plan is for the entire cayenne  
> model,
> data nodes and all, to be built up in code during system init (hot  
> model
> deploys are for another day).

This can be done, although as Ari said, this may require some work.  
I've done it in the past though... Such project is fairly bearable.  
Hot (re)deploys are also possible.

> Now for the more interesting part.  The goal is for this meta model  
> to be
> definable/relatable across data sources, even to the extent that the  
> source
> is not an RDBMS.  A great initial example is our Alfresco integration:
> users can define data classes that should be stored in Alfresco,  
> content +
> meta.  Those classes could then be related to a class that is stored  
> in our
> internal, Cayenne-managed DB.  FKs would be stored across the  
> sources for
> "joins", etc.  The data source would be defined in our meta config  
> in such a
> way that the various find/save service methods are exposed in a  
> uniform
> way.  In my dreamland I could search for a Cayenne-managed entity  
> ("Person")
> via a nested property ("pictures.mimeType") where Picture was an
> Alfresco-managed entity and mimeType was a property defined/stored  
> there,
> but that is clearly a challenge without DB joins..

Relating across different persistent engines can be tough. Relating  
between different DataNodes in Cayenne is possible with some  
limitations. You can store / update objects across DataNodes; you can  
fetch relationships; you can perform SelectQueries with qualifier  
crossing such relationships only if it does not require a SQL join  
across DBs. I.e. a select on an FK will work; a select on a property  
of a related object will not.


> So Question #2:
> Is it possible to work with/customize Cayenne in such a way that I  
> could
> make use of many of the ORM concepts (dirty-object management,  
> caching, etc)
> but inject code in the correct places to do customized find/persist
> routines?  What are the current limitations of cross-DataNode  
> cayenne model
> support?  The alternative I suppose would be for us to write a layer  
> above
> Cayenne that delegated down to the appropriate data source manager
> (CayenneManager vs AlfrescoManager or whatever) but that idea isn't  
> exactly
> appealing..

Don't see an easy way to do things transparently for a mix of Cayenne/ 
Alfresco objects via an ObjectContext. You may investigate custom  
queries, but I am with Ari on that - too much work to do it right. So  
yeah, something on top of both may be needed.

Andrus