On 30/05/2007, at 7:16 PM, Andrus Adamchik wrote:
On May 30, 2007, at 8:04 AM, Lachlan Deck wrote:
I'm not familiar with the embeddable discussion but this is the
idea of DbEntity interfaces:
a) you have a series of DbEntities that are not inherited in any
way but for which you want them to conform to an interface 'A'.
They are explicitly tied to that interface (rather than having to
synchronise to it). i.e., the attributes/relations appear as they
do for inherited characteristics. i.e., they're defined once per
model and implemented by various other DbEntities.
b) an ObjEntity interface 'a' may optionally map to a DbEntity
interface 'b'. Any ObjEntity 'c' that maps to a DbEntity that
implements 'b' will be shown to implicitly implement the
associated ObjEntity 'a'.
c) then there are the ObjEntity interfaces that have no associated
DbEntity interface...
What I am concerned about with DbEntity interfaces is that
DbEntities model database tables and there is no interface concept
in DB world. So I still don't understand why we need DbEntity
inheritance? Could you please elaborate or give some examples?
There's no need for DbEntity inheritance per se. But interfaces can
extend other interfaces. These DbEntity interfaces also have
ObjEntity equivalents. (see below)
The only use I can see for it is a *coincidental* match between
groups of attributes in multiple tables.
In terms of the generated sql, and so far as the database is
concerned, that is correct. However, when we're talking about an
enterprise mapping tool, where business/application logic/constraints
are defined (and exported to a database, java code, the runtime
environment, etc), then I think it's a valid concept that 'makes sense'.
i.e., in terms of the developers application of such a schema,
interfaces seem to me to be a natural modelling task.
So is it worth complicating the mapping by introducing a concept
with no analog in the DB world? My suspicion is that it will be
very hard to explain to the users.
I wouldn't have thought it would be a difficult concept to grasp. But
perhaps I need to provide a better use-case.
We have a web application that contains numerous entities. Most of
these are populated via soap from numerous remote applications. In
order to support the integrity of such replication each entity
adheres to a simple (though currently imaginary) interface:
Replicatable.
Now you might say 'well you can just create an ObjEntity interface to
create the appropriate java interfaces'. Of course that is true,
however for mine that is approaching the problem backwards and
requires more work and more accidental DbEntity mapping in the first
place seeing as this particular interface requires each entity to
persistently store certain data. The natural order of such mapping
begins with the DbEntity layer where each entity needs to adhere to
this protocol. Each ObjEntity counterpart will similarly validate to
implement the counterpart ObjEntity interfaces of the DbEntity
interface.
Let's say that a sub-set of these entities need to adhere to an
additional, yet supporting, protocol. Thus the need for interface
inheritance on the Db layer.
Let's say that, later on, we need to change the interface (e.g.,
adding two more fields). With what I'm suggesting the change is
simple, almost one-click. i.e., change the db-entity interface,
synchronise the ObjEntity interface with it, save the model,
regenerate classes etc. Without the interface in the Db layer it
requires copy/paste for each and every db entity and so on... as I
mentioned that's more work and for mine, less logical :-)
The main purpose of this concept is the logical mapping of
application-logic into a medium that has no such knowledge.
Of course, there are going to be times when someone may wish to map
an ObjEntity interface that has no Db counterpart. That is an
additional option seeing as with the inheritance concepts we're
allowing ObjEntity to have dbEntityName="".
Does that clarify where this concept is coming from? Personally, I
think this would take the enterprise mapping to another level.
with regards,
--
Lachlan Deck
