Mailing-List: contact cayenne-user-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cayenne-user@incubator.apache.org
Received-SPF: pass (asf.osuosl.org: local policy)
Mime-Version: 1.0 (Apple Message framework v746.3)
In-Reply-To: <4429BA24.5090107@synect.com>
References: <995b0fb00603031629p78bd7770j7c22721ab024440f@mail.gmail.com>
	 <B46FC167-C8FD-4EB2-808B-906FCF6ADAD6@objectstyle.org>
	 <995b0fb00603102134p182ab002ka85c7da505593a12@mail.gmail.com>
	 <007d01c64542$21de1b40$14b2a8c0@PC>
	 <8f985b960603111333u1a47f48dk9ef6e7e29df870bd@mail.gmail.com>
	 <001301c64561$024cce10$14b2a8c0@PC>
	 <8f985b960603111612k5b1d3d0ao1d3133cc822203c2@mail.gmail.com>
	 <007a01c64572$6b5e2c80$14b2a8c0@PC>
	 <8f985b960603111918w1f47622bg79291bae11941fb@mail.gmail.com>
	 <6684dff50603120015j14e0b3den4f18eb4dc3910a34@mail.gmail.com>
 <8f985b960603121324x24d573fcs1d1010dadb0330f1@mail.gmail.com>
 <4429BA24.5090107@synect.com>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <53D8E0AA-6CE9-4FFE-B74E-AA2B64646FDB@objectstyle.org>
Content-Transfer-Encoding: 7bit
From: Andrus Adamchik <andrus@objectstyle.org>
Subject: Re: Considering options for supervised database access
Date: Wed, 29 Mar 2006 10:42:16 +0400
To: cayenne-user@incubator.apache.org

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
>