On 4 February 2015 at 22:39, Hardy Ferentschik <hardy(a)hibernate.org> wrote:
On Wed, Feb 04, 2015 at 04:34:28PM -0200, Marc Schipperheyn wrote:
> Yeah, I'm now seeing that parent.id is not actually stored as numeric.
> However, when I project on it, it's returned as a Long for some reason.
> Hmm, confusing.
all "id" fields receive special treatment, for example the @DocumentId
is automatic, and we never encode these as Numeric. This should allow
us to take advantage of some of the neat stuff of Lucene 4, like joins
or DocValue on ids. With a NumericField these are not possible, but
you can definitely add the same field as a @NumericField as well.
That's the same reason which you'd use the very specific
IndexedEmbedded(includeEmbeddedObjectId) boolean attribute, rather
than using the "paths" attribute: ids are a special case. Given the
confusion, I'm wondering if we shouldn't hide them completely, as in
prohibit projection on the special field, as disallow queries to
target "our" id field. We could still allow users to add a custom
field as usual, and target that... that would maybe be slightly easier
to use, but I fear it could be more confusing as in some advanced
cases we wouldn't be able to fully hide this internal field. Not
least, it would be bloating your index with some duplication.
That's just the background. In practice though, Projection results are
independent on how stuff gets encoded: a query will always return the
type you're using in your class.
So in your specific example it's returning a Long because your field
type is a Long. If it's using a NumericField to encode that, that's an
Sorry for the confusion, suggestions to improve on this are very welcome.
I am also seeing some strange behaviour using projections when playing with
some tests for HSEARCH-1791. I am taking a closer look at this...
hibernate-dev mailing list