> 2. use an array of property values `cache.put( new Object[] {"Emmanuel",
> "Bernard"}, mapRepresentingUser );`
>
> Will that work at all? Does ISPN really work with value equality for
> array-typed keys?
>
> In a normal hash map you wouldn't get the value back as new Object[]
> {"Emmanuel", "Bernard"}.equals( new Object[] {"Emmanuel", "Bernard"} ) is
> false. So you would have to put the key into a wrapper whose equals method
> uses Arrays.equals() internally.
OK
>
> 3. use a Map<String,Object> corresponding to the array `cache.put( new
> HashMap<String,Object>( {{ "firstname" -> "Emmanuel", "lastname"->"Bernard" }
> ), mapRepresentingUser );
> 4. use an synthetic key `cache.put( new PersistentEntityKey( new String[]
> {"firstname", "lastname" }, new String[] { "Emmanuel", "Bernard" } ),
> mapRepresentingUser);`
>
> In 1, the problem is that we lose the proper data type abstraction
> between the object model and the data stored. `Name` is a user class.
>
> In 2, I think the model is somewhat acceptable but a bit arbitrary.
>
> In 3, I suspect the map is pretty horrific to serialize - that could be
> solved by a externalizer. But more importantly the order of the id
> columns is lost - even though it might be recoverable with
> EntityKeyMetadata?
>
> In 4, we expose the person querying the grid to our OGM specific type.
>
> The current implementation puts a PersistentEntityKey designed as you
> describe into the cache, but the externalizer only writes the column name and
> value arrays. This should be readable without knowing the PEK type, right? Of
> course you need to know the structure of the persisted key in order to read
> it back.
What I am not sure about is whether one can have the same externalizer id
plugged to different unmarshallers depending on the node / classpath you live
in.
But take the M/R framework of Infinispan today, it would require to put the
PersistentEntityKey class in the CP of all nodes at present.
>
>
> Now Davide's idea was to only write the column value array, as the column
> names are not really needed (assuming that one cache never contains entries
> from several tables). This seems sensible to me unless I'm missing some
> special case. The persisted form would be basically the one from 2., only
> that there is a wrapper used at the API level.
As Sanne mentioned, a case for keeping the column names would be if the id
structure changes somehow. One would need a way to distinguish the old from the
new representation. There are many ways to approach that:
- keep the structure in back key
- do the schema reference Sanne mentions
- rename the existing cache TABLE_OLD and migrate the data on the fly from
TABLE_OLD to TABLE_NEW
In most NoSQLs things are rather proposed and encouraged, in the data grid
space it’s do whatever you want. The question is which options do we want to
support for the grid. For example Sanne’s schema reference feels very intrusive
to me. It’s something that should be handled by the NoSQL system if it was
meant to offer such approach.
>
> Aside from this, it is essentially like 4.
>
> === Entity key approach
>
> I really like the idea of the simple case be mapped directly, it makes
> for *the* natural mapping one would have chosen. But as I explained, it
> does not scale.
> In the composite id case, I don't really know what to chose between 2, 3
> and 4.
>
> So, should we go for the simple case if we can? Or favor consistency
> between the simple and complex case?
> And which of the complex case do we favor?
>
> My preference would be 4, with the proposed change of only writing the column
> values. For the "simple case" we'd then could either store an array of size 1
> or just the single value itself, wrapping it into an array when reading it
> back. I guess that'd require an instanceof call during read back. Not sure
> whether that's good or bad, probably I'd just always store the array.
I don’t think you can quite do that. To be able to do an instanceof, you need
an instance. And to build that instance from bytes, you need a type.
_______________________________________________
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
