Le 8 déc. 2009 à 06:41, Rickard Öberg a écrit :
> 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.
Yup, you are right, I remember finding serialized (not jsonized) Set<> a
couple of months ago but they all seems to be correctly handled (now?)
I was not able to follow the evolution of the json serialization format since I
zip everything and I am (not yet) able to unzip what I read (I know, it is a
shame).
>
>> 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.:
I can confirm that at least 20% of the content stored is type info for me (not
a real problem, but it is ugly).
>
> @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.
Looks like all of this could be related to the infamous 'migration' mechanism.
Is there anything planned regarding migration ? (Sorry but qi4j's JIRA and Git
seems to be down)
>
>> 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?
Should be, Property<Map<>> does not work... but I can live with that ;-)
phil
>
> /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
