HSearch Projection queries & multiple fields with same name
by Marko Lukša
Hi,
we've found the following problem regarding projection queries when
dealing with documents containing multiple fields with the same name.
Let's say we add field "foo" with two different values to the same document:
luceneOptions.addFieldToDocument("foo", "aaa", document);
luceneOptions.addFieldToDocument("foo", "bbb", document);
If we now do a projection query on field "foo", one would expect the
resultset to contain exactly two results ({"aaa"} and {"bbb"}), but
HSearch returns only a single result (the property value of the result
is either "aaa" or "bbb", because Document.getFieldable("foo"), which is
called in o.h.search.engine.impl.DocumentBuilderHelper, returns the
first field that matches the given name).
DocumentExtractor.extract() returns a single EntityInfo, but in order
for it to properly handle projections as described in the previous
paragraph, it should really be modified to return List<EntityInfo>.
This sounds pretty reasonable when the query is projecting only a single
field. When projecting multiple multi-valued fields, the resultset
should actually return a cartesian product.
This is one way of doing it. The other way of doing it is if we
consider multiple fields with the same name as a single multi-valued
field. When projecting such fields, the resultset would contain the same
number of results as there are matching documents, with the projected
value being a collection of all the values stored in the field.
Actually, in CapeDwarf we need the cartesian product, as this is the way
Google AppEngine does it.
What do you guys think?
Marko
11 years, 3 months
[H-SHARDS] moving to hibernate orm 4
by Strong Liu
Hi,
Just want to let you know, I took some time of today ( my last new year holiday day ) and tried to migrate hibernate-shards to use hibernate orm 4.x
I pushed things to my fork(hibernate4 branch) https://github.com/stliu/hibernate-shards/tree/hibernate4
have finished the following things:
1. document building works fine now
2. compilable, there were lots of package changed
to-do:
1. transaction management
hibernate orm 4 uses TransactionCoordinator, which causes lots of tests fail in Shards
2. service registry
3. lots of other things I don't know yet :)
------------------------------
I only pushed the change to my fork, so, means it is not finished yet, but I do think this project at least should base on hibernate orm 4, not hibernate 3.x
-------------------------
Best Regards,
Strong Liu <stliu at hibernate.org>
http://about.me/stliu/bio
11 years, 3 months
Re: [hibernate-dev] [OGM] Should IN_ENTITY not only be used for OneToMany associations ?
by Emmanuel Bernard
Hello Guillaume and happy new year to you too.
You are partly correct. At some point we will want to offer the ability
to denormalize the information and copy the data of an entity when it is
associated via a to-one association. This will be useful to load
associated graphs in one lookup instead of two today.
But as it is today, to-one associations are always IN_ENTITY as we
always have the foreign key value in the document. That's exactly what
is happening when you use IN_ENTITY for a to-many association in
MongoDB, we store the association information (ie foreign key values) in
the entity document. Frankly, I don't think copying the foreign key
value of a to-one association is a separate document makes much sense:
- FK are small
- by definition, to-one only point to one value
so the payload is minimal.
Does that make sense?
Emmanuel
On Wed 2013-01-02 15:40, Guillaume SCHEIBEL wrote:
> Hi guys,
>
> First of all, happy new year I wish you the best (and to your relatives as
> well).
>
> Lately I was wondering how can we use in IN_ENTITY association storage
> principles for ManyTo* associations. I can't find a use case on that.
> For example, if I have this:
> - an entity Message
> - an entity Comment
> - a message is association to many comments
> - a comment is associatied to exactly 1 message
>
> So in this case, the IN_ENTITY mode is relevant and useful because I won't
> "never" access to Comment(s) other than by the associated message.
>
> But currently we are not making any differences regarding the type of the
> association I think we will need to/ have to create some specific sets of
> annotations for association type, right ?
>
> What is your opinion on that ?
> Thanks
> Guillaume
11 years, 3 months
[#HHH-4688] Make sure @OrderBy works for @ElementCollection - Hibernate JIRA
by Strong Liu
org.hibernate.test.annotations.collectionelement.OrderByTest was introduced by this JIRA, and it passes on master.
The question is, org.hibernate.test.annotations.collectionelement.Products#widgets, used in this test, which has @ElementCollection on it and its element type is an @Entity
but according to the JPA SPEC
{quote}
@ElementCollection
Defines a collection of instances of a basic type or embeddable class.
{quote}
so, is this a hibernate specific feature or we should "correct" this test?
-------------------------
Best Regards,
Strong Liu <stliu at hibernate.org>
http://about.me/stliu/bio
11 years, 3 months
