Quoting Niclas Hedhman <[email protected]>:
Can you elaborate on what do you mean by this (I can't even guess)??
Perhaps you even have some pointer to articles describing what you are
talking about...
Because breaking out UoW et al into an extension is not easily
achievable in a usable fashion, so we would need to see "another side"
before even thinking of doing this.
Yeah, well the point is that there still yet to come plenty of
articles about this project I am working with. And thus it's all a
little bit hush-hush yet. :)
But, maybe I can explain it a little bit better.
Our software environment consists of multiple applications. They may
be written in various programming languages. The integration
architecture for that is already thought-through, so that is not an
issue.
All the data is kept in a single repository (for now). The
applications may access the data simultaneously, either reading it, or
writing, or creating. Also, the applications may be interested in some
piece of data, for which they receive notifications, when other
application (or itself) does any kind of change.
The data integrity is extremely important, therefore we use SQL
database. The way data is stored in it is spred over multiple schemas
with different table design. The table design is fully dynamic, and it
varies from schema to schema based on what kind of data is stored
there. However, there does exist a logic based on which the data may
be accessed in a uniform way. This makes it very unsuitable for Qi4j
Entities as they are now, since a Qi4j Entity of type X with ID Y
would need one kind of UPDATE statement, but Qi4j Entity of *same
type* but *different ID* would need another kind of UPDATE statement.
Because of the software environment, the creation of data is very
repository dependent. Basically, when committing a transaction holding
the data creation statements, the resulting IDs of created data is
returned back. So, we only know the real IDs *after* committing the
transaction in which they were created.
Additionally, the actual ID's are currently consisting of three
integers. And Qi4j's identity is just a String. It could be possible
to somehow circumvent this with some hacks, but I think that would be
very non-Qi4j way to do it.
Basically, ideal for this case, the Qi4j Core could either provide the
way to "plug in" some implementation of Entity/UoW support, or the
current Entity/UoW would need to be *extremely* extensible and
customizable.
But, it is in no way really necessary. I understand that the usecase
of Qi4j that I described is quite a niche one, and I don't expect
anything to change in the Core. I still can use the Core and implement
my own system for custom entity/UoW handling (very very tedious, but
pretty much the only choice). The code generation and the application
features (modules, layers, singletons of Services,
Object/Transient/Value builders) of Qi4j is something that always will
be used IMO.
_______________________________________________
qi4j-dev mailing list
[email protected]
http://lists.ops4j.org/mailman/listinfo/qi4j-dev
