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

[Emmanuel Bernard]

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