Hi Craig,
I am still on my first cup of copy this morning, so I may not be
following you completely, but I'd think that that remote object
persistence feature is close to what you describe:
http://objectstyle.org/confluence/display/CAY/Remote+Object+Persistence
Basically here Cayenne client accesses Cayenne server, with both
layers based on Cayenne API, and both implementing arbitrary business
logic.
Actually even in a single VM you can partition logic with nested
DataContexts. DataContext accesses data store via a DataChannel,
which can be implemented by a DataDomain, another DataContext, or it
can be your custom facade wrapping a DataContext. DataChannel is a
virtual object data source.
Such multi-layer capabilities is a signature feature of Cayenne 1.2.
I am sure it will lead to previously unforeseen uses.
Andrus
On Mar 29, 2006, at 2:35 AM, Craig Turner wrote:
This was from the thread "Re: violates not-null constraint question."
Mike Kienenberger wrote:
And it's not like I came up with this brilliant thought on my own
either -- I also thought I should be able to use DB default values
when I first started using ORMs. I also had to have it explained to
me as well :) The same thing applies to auto-increment db-side
generated primary key values, although Andrus (and others) have
worked
out the methodology to "read-back" that db-side generated value.
This thread has reminded me of a similar issue I've been mulling
over for a while.
At the OpenBase conference last year one of the users made a
request during the feature request system for some sort of in-
database constraint system. I think what he wanted is for multiple
applications to be able to access the database tables directly and
have the database complain if they tried to do something nasty.
My initial reaction was that he misunderstood the domain and then I
thought - no - I can think of good reasons why he might want this.
I told myself to be open minded and decided that what he wanted
sounded reasonable. Basically - he wants supervised access to the
datastore rather than proxied access which is what tends to get
used by developers at the moment.
I know of two typical methods to shielding databases, both of them
supervised: stored procedures and RPC engines, which are
conceptually the same thing - an exposed API.
I'm not thrilled about stored procedures as an answer to this
situation: they're not particularly convenient to work with for
ORBs, you can only do what's allowed by the API, and methods can
have side-effects which are not apparent to users. As for RPC:
while this is nice in theory, in practice I think it's very heavy-
handed, and it means applications outside that have to use that
same sort of limiting API-style access.
Maybe my initial reaction was correct - having multiple autonomous
apps access the same datasource directly is completely out of the
question and the only way to have them share data is to wrap it
with an engine. But I'm not convinced.
I wonder whether there could be some sort of virtual objects that
behave and are managed like cayenne entities but which map to a
java engine instead of mapping to a database. The engine would not
have a traditional API of exposed methods, rather than having an
exposed schema of data-objects, just like a database does, and from
the app-programmer's perspective, accessing this through cayenne
would be just like accessing a database.
In addition to having just:
App ---- [cayenne] --> db
you could then have:
App ---- [cayenne] --> engine
An alternative to putting the burden of developing this on cayenne
would be to have a virtual datasource that appeared to the outside
to be a database but which behaved quite differently and was
streamlined for this sort of usage.
Any thoughts/suggestions?
- C
