Thanks for the quick responses guys.
Ari-- I hear you. Your concerns are perfectly valid and it's definitely
something I'm trying to tightrope. We are in the (probably customary)
position of being a small custom-software company that has aspirations to be
more than that. We've had several false-starts on a truly reusable
framework across clients, which is OK (at least we *have* clients), but our
current development cycles aren't conducive to growth. In the meantime our
visionary CEO is constantly looking for how software we've written can be
repurposed for another client, which is where all of the antipatterns you've
mentioned begin to creep in.. the only way to truly repurpose is to
genericize.
All of that said (and I've been around these sorts of projects before).. I'm
not getting the "uh oh" feeling quite yet. The main reason behind a
separate modeller is because of the cross-platform data source concept I
mentioned, so the scoping is different. It's an idea that may gain traction
down the road but I'm not putting an ounce of dependency on it at this
time.. like I said, I'm working backwards from a cayenne model at this point
and it works fine. The runtime code is using a generic DataObject class
*most* of the time, but I do have some situations where attempting to
describe a complicated object relationship in generic terms would lead to
the Expert System problem so I can back down to a concrete class. The nice
thing about Cayenne is I have the option.
Our biggest integrations are Alfresco for ECM and Mule as a bus. The Mule
services operate as "real" code, working off of interfaces. The Cayenne
data objects can either a) implement that interface directly if a concrete
class is provided, or b) be implemented dynamically via a Proxy if generic.
The nice thing about this approach, I think, is that we can start small
(implement all entity types if needed) and work our way towards the more
generic solution. I still contend that if we could move 80% of a particular
client's needs into a common codebase, and custom develop the remaining 20%,
then we will be doing great.
Have you guys dealt with a query situation like the one I described (cross
database or cross platform)? What have you found works best? I could also
consider data synchronization across Alfresco and our internal DB for query
purposes..
On Mon, Mar 2, 2009 at 10:44 AM, Andrus Adamchik <andru..bjectstyle.org>wrote:
> 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
>
>
This archive was generated by hypermail 2.0.0 : Mon Mar 02 2009 - 12:18:23 EST