cayenne-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Craig Turner <cr...@synect.com>
Subject Considering options for supervised database access
Date Tue, 28 Mar 2006 22:35:16 GMT
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

Mime
View raw message