What if the QualifiedIdentifier is expanded to also contain the version?
Then the client is saying: Give me the state of this 'thing' formatted
in version 2 of type Foo?
A (complicated) refactoring could be to change version 2 of type Foo
to version 1 of type Bar.
This must be acompanied by a migration changing the persistent
entities from the old to the new format.
But what if we also required the refactoring to be acompanied by the
reverse migration changing from version 1 of Bar back to version 2 of
Foo?
Then the entitystore should know that when it receives a request for
version2 of Foo, it has to find the instance stored in the newer
format, and then migrate it backwards before sending it to the client.
As a consequence of this, when the refactoring is applied to the
entitystore it might decide to not migrate the state of all persistent
instances at once, but only (asynchronously?) as they are accessed
(maybe the state is only being used from old clients, that would
prefer the old format anyway).
The reverse migration could be optional, in which case getting state
in the old format is of course not supported.
WDYT? Too complicated?
Med venlig hilsen / Kind regards
Kent Sølvsten
Den 25/03/2009 kl. 05.35 skrev Michael Hunger:
I agree. EntityState doesn't have to know about the type as it ist
just a dumb state holder.
State gets relevant when used at the client.
The version of then entity is included in the state. Why not also
the schemaVersion of the type at the time of storage?
So our QI ist just the UID without the type (as it is now?).
Then the UID really must be unique over all entities, right?
Seems a nice challenge for mapping stores :)
Michael
Am 25.03.2009 5:27 Uhr, schrieb Rickard Öberg:
Niclas Hedhman wrote:
The ID passed at that level is an opaque String? Would that create
problem for 'mapping'-like stores?
It would. But if we split the responsibilities of storing and
managing
type this could maybe be fixed. If EntityState did not include
EntityType, but it *is* provided EntityType on prepare(), then it
could
work I think. Maybe. Not sure at all...
Yes, I think that would make sense. In fact, UoW is fairly
overloaded
and perhaps there are other things it does that perhaps should be
broken out as well.
Most likely!
/Rickard
_______________________________________________
qi4j-dev mailing list
[email protected]
http://lists.ops4j.org/mailman/listinfo/qi4j-dev
_______________________________________________
qi4j-dev mailing list
[email protected]
http://lists.ops4j.org/mailman/listinfo/qi4j-dev
_______________________________________________
qi4j-dev mailing list
[email protected]
http://lists.ops4j.org/mailman/listinfo/qi4j-dev
