[hibernate-dev] hooking native MongoDB queries on mapped entities

Tue Apr 16 09:11:20 EDT 2013

I've applied the changes following Emmanuel suggestions:
https://github.com/DavideD/hibernate-ogm/commits/nativeq

I've created a very simple implementation of SqlQuery and with this
prototype it is possible to execute session.createSqlQuery(...) and
entityManager.createNativreQuery(...).

I've changed the the return type of the
MongoDBDataStoreProvider#executeNativeQuery(...) to a more generic
ResultsCursor that will return an iterator of Tuple.
At the moment the return type must be an entity class so that I can obtain
the collection where I can do the query and make the conversion form Tuple
to entity using the OgmLoader.

I'm try to understand how the core implementation of hibernate transform
an  Object into the return class but it still not very clear to me.

Native query with session:
https://github.com/DavideD/hibernate-ogm/blob/2dd6bd214d7a1970047310286efa70972528e04e/hibernate-ogm-mongodb/src/test/java/org/hibernate/ogm/test/mongodb/nativequery/MongoDBNativeQueryTest.java

Native query with EntityManagert:
https://github.com/DavideD/hibernate-ogm/blob/2dd6bd214d7a1970047310286efa70972528e04e/hibernate-ogm-mongodb/src/test/java/org/hibernate/ogm/test/mongodb/nativequery/MongoDBEntityManagerNativeQueryTest.java

On Thu, Apr 11, 2013 at 8:55 AM, Emmanuel Bernard <emmanuel at hibernate.org>wrote:

>
>
> On 11 avr. 2013, at 01:27, "Davide D'Alto" <davide at hibernate.org> wrote:
>
> > I think I would have put this contract on the dialect rather that the
> provider. What was your reasoning?
>
> The dialect seems involved in the conversion between the element used by
> the data store (node, relationship, document, etc.) and the representation
> we are using  (tuple, entityKeys, etc).
> In this case we are not interested in the representation of the data we
> just want to execute a query and return the object. This could be done
> without any dialect ideally. At the moment I'm using the Tuple class
> because is handy.
>
> In theory a user could just use the data provider to save objects, so I
> thought it would make sense to add to it a way to query the db as well.
>
>
> Maybe we will need a separate interface down the road but that's not
> important. One question on this though, would it make more sense to return
> an iterator of Tuples or some Tuple-ish constuct and let the Tuples to
> object be handled by the OGM engine itself?
>
>
> > I would not create a MondoDBOGMCursor or for sure not expose it to the
> API.
>
> Initially I've used an Iterator but then I've noticed that the DBCursor
> implements also the Closable interface. The Idea was to create a class that
> implements the same interfaces: Iterator, Iterable and Closable.
> Maybe we can give it a more generic name like ResultsCursor or something
> like that.
>
>
> Right
>
>
> > That way we can implement  session.createNativeQuery.
> Do you mean OgmSession#createSQLQuery(...)?
> I can try to work on a prototype, I guess the main problem is to implement
> an SQLQuery but I can give it a go.
>
>
> Yes. I was thinking more of EntityManager.createNativeQuery but
> Session.createSQLQuery is semantically the same. SQLQuery might have many
> unimplemented methods and if that's really too problematic, we can imagine
> a dedicated method but I'd like to avoid that.
>
>
> On Wed, Apr 10, 2013 at 6:31 PM, Emmanuel Bernard <emmanuel at hibernate.org>wrote:
>
>> That looks about right. Here are my comments.
>>
>> I think I would have put this contract on the dialect rather that the
>> provider. What was your reasoning?
>>
>> I would not create a MondoDBOGMCursor or for sure not expose it to the
>> API. Instead I would have two (or three) methods:
>>
>> - one returning the List<T>
>> - one returning an Iterator<T>
>> - one returning a ScorallableResultset<T> (optional for now)
>>
>> That way we can implement  session.createNativeQuery.
>>
>> Where I am not sure that approach will play well is for dialects like
>> Infinispan that need to rely on external search engines for queries. But
>> that might not be a problem.
>>
>> The cool thing is that the JP-QL might be able to reuse part of this
>> logic of not all for the beginning.
>>
>> In other words, Go go go! It might even be worth pursuing before the
>> metadata issue.
>>
>> Emmanuel
>>
>> On Wed 2013-04-10 17:25, Davide D'Alto wrote:
>> > I forgot to add the link to the commit:
>> >
>> https://github.com/DavideD/hibernate-ogm/commit/c0426378671b2e73c9450b43d55e09ba8af00f3c
>> >
>> >
>> > On Wed, Apr 10, 2013 at 5:24 PM, Davide D'Alto <davide at hibernate.org>
>> wrote:
>> >
>> > > As an experiment I've added a method to the mongodb provider:
>> > > MongoDBDatastoreProvider#(Session session, String sqlString, Class<T>
>> > > entityType)
>> > > With this method it is possible to execute a native query like "{
>> $query :
>> > > { author : 'Oscar Wilde' }, $orderby : { name : 1 } }" that will
>> return a
>> > > MongoDBOgmCursor that is similar to the DBCursor except that it
>> returns an
>> > > Object of the type entityType.
>> > >
>> > > I'm using the same approach used for the OgmMassIndexer therefore the
>> > > return type must be en entity.
>> > >
>> > > Do you think something like this can be useful?
>> > >
>> > >
>> > > On Mon, Apr 8, 2013 at 12:09 PM, Emmanuel Bernard <
>> emmanuel at hibernate.org>wrote:
>> > >
>> > >> From what I understand, this would be equivalent to the
>> > >> @NAtiveNamedQuery support in JPA where you define the binding between
>> > >> the result set and the objects. We can give it a shot. I wonder how
>> much
>> > >> of this is related to the JP-QL query mechanism though and should be
>> > >> shared.
>> > >>
>> > >> Emmanuel
>> > >>
>> > >> On Sun 2013-04-07 14:19, Sanne Grinovero wrote:
>> > >> > Looks like a good idea:
>> > >> > https://forum.hibernate.org/viewtopic.php?f=31&t=1025793
>> > >> >
>> > >> > Davide can you help them figuring out how to hook it all up?
>> > >> >
>> > >> > Sanne
>> > >> > _______________________________________________
>> > >> > hibernate-dev mailing list
>> > >> > hibernate-dev at lists.jboss.org
>> > >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> > >>
>> > >
>> > >
>>
>
>