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.

On 4 February 2015 at 22:39, Hardy Ferentschik <hardy(a)hibernate.org&gt; wrote: Hi Marc, 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 unrelated concern. Sorry for the confusion, suggestions to improve on this are very welcome. Sanne