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 : Tue Mar 28 2006 - 17:35:42 EST