Thanks,
I am in the process of converting as much as possible all my entities
to values (my model was composed of entities only).
One of them (the Contract value) has 8 mixins and a 'base' value, so
yes I do use VC subtypes (the reason for my hack-see previous message).
BTW, I think this specific _type field could be used for migration
purpose later... (by imposing a new type or mapping between old->new
types).
Could you please tell me when you plan to implement the _type field ?
Also, FYI, there is no checking about circular references in VC (stack
overflows) and I don't understand the semantics of Property<Entity>
(it is allowed).
Phil
P.S.: And congrats, there is only one cycle in the core-api project...
a-ma-zing!
Le 27 août 2009 à 06:01, Rickard Öberg a écrit :
philippe van dyck wrote:
so to be sure I understand everything correctly :
1) to JSonize values, we currently use the same mechanism as
Serializable types, this mechanism stores the type info too
Actually it didn't. It just stored the serialized Value as base64'ed
JSON.
2) we need to store the type info (because since it is embedded in
an entity it is not managed by the ES)
Yes and no. If you can live with the restriction that if you use
"Value" as declared property type there can only be one possible
implementation (e.g. "ValueComposite"), then it's fine. It's only
the polymorphic case that is tricky, and we'd have to include type
info.
3) one solution is to use Property<ValueComposite> instead of
Property<Value> (serious problems with dependencies & Structure4J)
4) there are two different aspects : store the type / store the
value, both are currently solved using the Serializable type (hence
hiding the content of the Value)
5) there is no added value to JSonize the values for the moment
(since they are serialized and unreadable in the stored format)
Yup.
Don't you think we really need to find a solution to expose the
type and the JSon content of the values to stabilize the storage
format ?
I've just committed a change to SerializableType (and associated SPI
changes to make it work). Basically, if SerializableType notices
that the value is a ValueComposite it serializes it as a regular VC
using JSON. So, the output is just JSON. As long as you can live
with the restriction "one base interface->one value interface" this
would be fine.
One thing to consider is the option of including a special JSON
field named "_type", which has the classname of the instance. If you
have two VC's SomeValue and OtherValue, where OtherValue extends
SomeValue, and then you serialize a property declared with SomeValue
as type, then if the value actually *is* SomeValue then no type info
is included. Otherwise the "_type" field would be added. The idea is
to leave out type info as much as possible and keep the format to
data only, but if necessary then include the type name. This is only
relevant if people start doing VC subtypes, which I'm not sure how
popular it is going to be.
/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
