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? > 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. > 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!)... > 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. > 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. > 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... ) Cheers -- Niclas Hedhman, Software Developer http://www.qi4j.org - New Energy for Java I live here; http://tinyurl.com/3xugrbk I work here; http://tinyurl.com/24svnvk I relax here; http://tinyurl.com/2cgsug _______________________________________________ qi4j-dev mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/qi4j-dev
