2014-06-19 13:34 GMT+02:00 Emmanuel Bernard <emman...@hibernate.org>:
>
> On 19 Jun 2014, at 11:12, Gunnar Morling <gun...@hibernate.org> wrote:
>
> I'm looking into this atm.
>
> My thinking is to pass a new dedicated Type IdGeneratorKey instead of
> RowKey to GridDialect#nextVal() which can carry all the information we
> need. The dual use of RowKey for association rows and sequences has been
> confusing anyways.
>
>
> Yes that’s a good idea.
>
>
> 2014-06-06 10:44 GMT+02:00 Emmanuel Bernard <emman...@hibernate.org>:
>
>> I guess it is particularly questionable to have an identity generator be
>> mapped to an ad-hoc table based generator. Remember the angle we came from:
>> make a JPA application work when storing data in Infinispan. Unlike other
>> datastores, Infinispan has not notion of id generation whatsoever.
>>
>> sequenceName should map to on of the OgmTableGenetator settings somehow.
>>
>
> +1
>
>
>> valueColumnName is something that I elected no to use because NoSQL we
>> bind to so far do not have a strong schema. And at at given
>> segmentColumnValue only correspond a single value. It would come and bite
>> me if someone for the same segment value had two different value column
>> names to differentiate two different sequence.
>
>
> Would it really bite you? I think e.g. MongoDB could perfectly handle this
> case via two different fields for the two sequences in the same
> document/segment.
>
>
> @TableGenerator(
> name=“1”,
> table=“Seq_table”,
> pkColumnName=“key”,
> pkColumnValue=“1”,
> valueColumnName=“value1”
> )
> @TableGenerator(
> name=“2”,
> table=“Seq_table”,
> pkColumnName=“key”,
> pkColumnValue=“1”,
> valueColumnName=“value2”
> )
>
> The two definitions share the same options except for valueColumnName.
> The table is roughly as followed
>
> TABLE(Seq_table)
> key | value1 | value2
> 1 | 10 | 24
>
> What would be the MongoDB representation in your approach?
>
It would look like this:
{
"_id" : 1,
"value1" : 10,
"value2" : 24
}
So you would get the different sequence values from different fields of
that same document. But I wouldn't recommend to do so due to the potential
contention on that single record. Thus I'd raise at least a warning during
bootstrap. As it's not portable to stores with a fixed schema, I'd rather
not support it at all, though, and raise an error.
> But as this does not really seem like a best practice, we could also
> handle it as a definition error if the same table is used with different
> value column names in different generators. We could raise an error during
> bootstrap.
>
>
> I am not a huge fan but I could live with that as long as it is detectable.
>
_______________________________________________
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
