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
>
This archive was generated by hypermail 2.0.0 : Wed Mar 29 2006 - 01:42:48 EST