Kent Sølvsten wrote:
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?
The thing is that if you specify the version then you don't need the
type, since our versions are hashes of the type, and so from the version
you can infer the type. It mostly comes down to: can the client of
EntityStore know what type it wants, or should it just say "get me the
object with id 123" and then see that the type of 123 is different from
what it expected, and then do the refactoring. This is really how the
web works, for example: you access a URL, get the document, and then the
client can see what HTML version is used, and "upgrade" it on the spot
so it can be read with a newer client. Then the client can optionally
store back the updated version.
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?
Reverse migrations are likely not feasible. Time generally moves
forward, not backward.
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?
Yes :-)
I am leaning towards changing so that EntityStore only has to deal with
data, and not type at all. Meaning, getEntityStore() will only have id
as parameter, but the returned EntityState *will* include the EntityType
that it was stored with. Where did it get the EntityType from? It was
included in the prepare() that caused it to be stored in the first place!
Michael noted that mapping stores might be in trouble. To some degree
yes, but it can be worked around I think: on prepare() the EntityState
sent in would contain the type, and so from there the mapper can choose
what tables to store the entity in. It would however have to also store
an extra table of id->type, so that when getEntityState() is called
without the type it first looks in the id->type table and then looks for
the id in the table that stores "type". That should work, even though
it's slower.
/Rickard
_______________________________________________
qi4j-dev mailing list
[email protected]
http://lists.ops4j.org/mailman/listinfo/qi4j-dev
