On 2009-12-08 13.29, philippe van dyck wrote:
Actually the problem seems to come from a Property<Set<Value>> ... I
don't know to what case it belongs.
If "Value" extends ValueComposite, then Qi4j should figure it as a
CollectionType that contains a ValueCompositeType. If "Value" does not
extend ValueComposite, then it should be a CollectionType that contains
SerializableType.
I read previously on the list (I think it came from you) about the
whole idea of "loading" an untyped entry stored (in an ES) "into" a
composite, and I find it very elegant.
Having a type-agnostic store looks definitely more efficient when you
think about maintenance (i.e. migration), but I did not find any
other way to solve this.
Skipping types is fine as long as there is no inheritance going on. Only
then is it necessary to store type info. It would be better to store
some kind of marker instead of the actual type though, both for space
reasons and migration. How to do that? Not sure. Having an annotation on
the type would be one option. I.e.:
@Type("myvalue")
interface MyValueComposite
{
Property<String> someValue();
}
--
When serialized we'd store "myvalue" instead of fqdn, and so if the type
changes name or package, it would still work. Heck, you could replace it
entirely with something else.
Why does it happen in the first place ?
Should we store some kind of type registry ? (sounds like a very bad
idea)
Yeah... we had that idea at some point, but I don't think it's
realistic. Too easy to get it out of whack. Using the current types of
the application/JVM along with on-the-fly migration seems more realistic
to me.
BTW, do you plan to create an "ArraySerialization" to store arrays
(or sets) of properties the JSON way ?
Well, we already have support for collections (e.g.
Property<List<String>> stringList()), so isn't that enough?
/Rickard
_______________________________________________
qi4j-dev mailing list
[email protected]
http://lists.ops4j.org/mailman/listinfo/qi4j-dev
