I should perhaps add, for someone thinking along these lines, that using a Link field works in the desired way if you don't mind a (identifiable) document being created for these values.
-Stefan On Friday, 14 August 2015 18:59:20 UTC, [email protected] wrote: > > Hi, > > OrientDB stored property names for all properties unless they have been > defined for ht E/V type. > > I'm looking for a convenient way to store an *EmbeddedMap* without > storing the same/few property names over and over again with all values > (basically trying to save disk/memory space). > > On idea is to use the *Embedded* field type to store an *ODocument*(defined > type with defined fields) as *Embedded*. > > This seems to have a few drawbacks from storing embedded maps: > > 1. The stored value: > {"@type":"d","@version":0,"PresentationValues":{"label":"SHINING"}} might > indicate that the document is store in it's JSON form as a string on the > hosting document > - If this is so than that would not save any space, on the countrary > it would take more space > - Can someone tell me how this is serialized? > > 2. A *EmbeddedMap* property with the same value {"label":"SHINING"} can > be queried: > - "select @rid, presentation.label from SomeTable" would select > SHINGIN > - When using a *Embedded* "select @rid, presentation.label from > SomeTable" would select noting > - Should it not be possible to select from *Embedded* in the same way > as *EmbeddedMap* > > Best regards, > -Stefan > > -- --- You received this message because you are subscribed to the Google Groups "OrientDB" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
