On 2010-01-28 19.06, Niclas Hedhman wrote:
If this is indeed a central piece of the overall strategy to drive
adoption, I think we should not do a less than optimal approach, the
least dependencies of others, and just do it right with our own set of
tools. The number of RDBMSes we need to support are small, and I doubt
we need any of the advanced extensions that typically drives RDBMS
inter-operability. The main remaining issue is "types", which can be a
hairy chapter (there are so many of them in each, and they are not
same even if they have the same name). But, personally I think it can
be managed fairly easy.
The main issue being that when we do UoW.get() we only get the identity
of the entity in, not the type. For traditional OR mapping that should
be an impossible mission, UNLESS the type is embedded in the id (possible).
First step is still to figure out what kind of support we would
provide. Hibernate, for instance, would support all kinds of mapping
from multiple tables, merging result fields to member variables,
sub-querying and what not. Should we go for an "anti-corruption layer"
approach where the 'mapping' is 1-to-1 between any existing tables to
newly written composite states, which then with composite mechanism
are exposed to the domain model? Probably need a Requirements
Statement, preferably in Jira around this whole topic or it can
quickly get out of hand, me thinks.
Yes, I think we need to have a requirements spec as well.
From what I've heard there seems to be two main cases for RDBMS:
1) People have existing schemas that they want to make an app on top of
2) People want the data in an RDBMS, because the operations folks know
how to handle that with maintenance, backup, etc.
Both are fair scenarios, so to speak. For 1), it seems to me that there
are two cases: 1.1) You'd want to write a new read/write app, i.e. the
core domain logic and 1.2) You want to write a new read app that works
with existing schema and someone else updates the data. Does this sound
reasonable?
For 1.1), it would actually be possible for us to make an RDBMS
implementation that uses the 1-table-trick, i.e. columns
id-blob-version-timestamp, so we make it look like a key-value store.
Then it is trivial to write an EntityStore for it, and we don't have to
mess around much. Then, since the Qi4j domain model now can be written
to that trivially, the reamining part is to make a service that takes
the written JSON and transforms it into data for the other "real"
tables. The upshot here is that this would be a StateChangeListener,
which gets EntityState *which contains the EntityType*! So the mapping
part should now be significantly easier to do, since more metainfo is
available.
All of the caching issues etc. is also unimportant, since that is
handled on the key-value level. Mapping ValueComposites to tables should
be easier, and so on.
For 1.2), use JPA. It won't buy you much to use Qi4j in that case I think.
For 2), see 1.1)
How about that? Am I making sense here?
/Rickard
_______________________________________________
qi4j-dev mailing list
[email protected]
http://lists.ops4j.org/mailman/listinfo/qi4j-dev
