" This affects current master branch , introduced by https://github .
In com/hibernate/hibernate-ogm-ignite/pull/18/.\r\n\r\nIn IgniteInitializer, a few special cases are matched and handled. UUID case is missing from those.
https \r\nhttps ://github.com/hibernate/hibernate-ogm-ignite/blob/master/ignite/src/main/java/org/hibernate/ogm/datastore/ignite/impl/IgniteCacheInitializer.java#L271
In \r\n\r\nIn the OGM docs at https://docs.jboss.org/hibernate/ogm/5.4/reference/en-US/html_single/#ogm-mapping-supported-types
It \r\nIt says \ "UUID stored as described by RFC 4122 \ " which I'm assuming means the string form of the UUID.
I \r\n\r\nI think as a consequence of this, hibernate-ogm-core ends up selecting `StringMappedGridTypeDescriptor` and this does a `toString` on the UUID object before passing it to the underlying store.
Apache \r\n\r\nApache Ignite supports UUIDs natively and since the ignite initializer sets the query entity's type to java.util.UUID, Ignite's GridH2RowDescriptor attempts to cast the incoming object to a UUID but this of course has been turned to a string by the StringMappedGridTypeDescriptor.
The \r\n\r\nThe end result is a ClassCastException. I don't know the internals of OGM (or OGM-ignite) but from the looks of everything else in that initializer I assumed adding an exception for UUIDs was the way forward.
I \r\n\r\nI 'm presuming OGM in general converts the UUID to a string so that there is a consistent representation for UUIDs regardless of the backing store, if so perhaps there's no way to take advantage of Ignite's native UUID support.
I \r\n\r\nI 've attached a stacktrace from when this happens and a patch adding the exception I mentioned. Feel free to use/apply it or implement another solution.
\r\n [^ogm-uuid-field-type.patch] [^ignite-class-cast-exception.txt] " |
|
