cayenne-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrus Adamchik <>
Subject Re: Considering options for supervised database access
Date Wed, 29 Mar 2006 06:42:16 GMT
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:

Basically here Cayenne client accesses Cayenne server, with both  
layers based on Cayenne API, and both implementing arbitrary business  

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.


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

View raw message