On 11 avr. 2013, at 01:27, "Davide D'Alto" <dav...@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 <emman...@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 <dav...@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 >> > > <emman...@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@lists.jboss.org >> > >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev >> > >> >> > > >> > > > _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
