Quoting Niclas Hedhman <[email protected]>:
On Tue, Aug 2, 2011 at 5:03 AM, Stanislav Muhametsin
<[email protected]> wrote:
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.
Is it fair to say that this is similar to accessing a third-party
service, such as ISO-8583 payment system where the 'schema' in reality
depends on the counter parties, creating headaches for the gateway??
Or are we talking about a CRUD store like GData but the data
structures are "owned" by other applications? Or something else?
More like CRUD store where data structures are 'owned' by the CRUD
store itself. If that makes any sense.
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.
This doesn't seem very different from what we have in the bank. There
are heaps of various in-house services providing views to datasets,
that one can 'fetch', 'subscribeTo' and 'publish'. Although I didn't
expose those as EntityStores, I possibly could have, but value would
be limited. Instead we chose to cache the datasets that we were
interested in "at the moment" and the entity store is the cache.
Yes, caching datasets that application is interested in 'at the
moment' is exactly what we are doing as well. Except that the cache is
in-memory of whatever application that accesses the repository. Entity
store can not be used in its current form, as the way entities are
stored may vary between entities of same type, as I explained below.
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.
Why is that? And how would figure out how to go from an ID to a
schema? I suspect that this is built-in to the external
infrastructure, but since you bring it up, it seems more like each
application is expected to deal with that (very BAD!)...
Unfortunately, I am not really allowed to say why. It just is like
that. I hope we will get some papers done on this project, so the real
reasons behind this will be public. And there are very heavy and
well-justified, built-in reasons for this situation.
If the answer seems stupid, maybe one can think of this kind of
situation: legacy blackboxed software that you must use, which you can
not modify, and which does things the way I described.
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.
Yes, that is a common "mistake" in SQL centric applications, which I
think in most cases creates more problems than it solves.
I kind of agree, but in this kind of situation, in order to avoid
primary key conflicts (where two or more applications happen to create
data simultaneously), that is the only option that I see.
Additionally, as this project involves many people with different
responsibilities, I can hardly affect this. But I also agree that it
makes things quite complicated on the application-side, but again,
simplifies the repository a lot.
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.
Not at all. Extend Identity with the method to set the custom 3 int
identity and the mixin implementation does the mapping back and forth
to String.
This is prone to errors (the order of integers, the possible future
changes to introduce maybe fourth integer). Still hacky IMO but less
hacky than I initially thought, since extending Identity did not come
to my mind.
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.
Sorry, but I have not gotten enough information to see what you are
doing at UoW level that requires a custom implementation. And since
UoW can dig deep inside the Structure system in Qi4j Runtime, I don't
see how you can honor the visibility rules either, as the 'view' of
visibility in the UoW follows the execution path (from method to
method). (We had a big deisgn flaw early on where the UoW had the view
from where it was created... )
It is true that I did not tell much of UoW level. This is still
undergoing project on Java side (fully completed on C# side), so not
much to say. But UoWs are so closely tied to Entities that using them
for anything else is not much of a point.
And I got a big hunch from C# side that 'our' UoWs will behave quite
differently from Qi4j UoWs. Or rather, that Qi4j UoWs have a lot of
stuff 'extra' that is handled elsewhere, or not needed at all due to
the design of our software. But hey, I might be wrong, as I said, that
part is still in progress on Java side.
And even adopting the Qi4j UoWs for this project would work, there are
still very big and unsolved problems related to Entities. Those are
that identities come from outside the application, that the way
entities are actually stored (in our case, SQL table structure) may
vary between entities of same type, and that the data may change at
any moment, and the entities must react to the changes made by other
applications.
Summa summarum, I think what I am after is "full control as to how
Entity state is serialized" and "full control as to how UoW retrieves
and caches entities". And I really mean "full control", with no
comporomises. This most likely favors "plug-innable Uow/Entity
implementations" over the "really extensible UoW/Entity arhictecture".
_______________________________________________
qi4j-dev mailing list
[email protected]
http://lists.ops4j.org/mailman/listinfo/qi4j-dev
