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

[Davide D'Alto]

> 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.

> 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.

> 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.

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
> > >>
> > >
> > >
>