3:19 p.m.
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
9:45 a.m.
Hi,
I'm interested by it, tell me if I can help.
Guillaume
2013/4/7 Sanne Grinovero <sanne(a)hibernate.org>
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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
1:30 p.m.
Hi Guillaume,
great, your help is always welcome but I didn't want to ask you as you
still have many pull requests open. Don't you have enough on your
plate already? But feel free to experiment with this idea, seems
someone would need to spend some time experimenting.
Sanne
On 8 April 2013 08:45, Guillaume SCHEIBEL <guillaume.scheibel(a)gmail.com> wrote:
Hi,
I'm interested by it, tell me if I can help.
Guillaume
2013/4/7 Sanne Grinovero <sanne(a)hibernate.org>
>
> 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(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
1:09 p.m.
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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
6:24 p.m.
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(a)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(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
6:25 p.m.
I forgot to add the link to the commit:
https://github.com/DavideD/hibernate-ogm/commit/c0426378671b2e73c9450b43d...
On Wed, Apr 10, 2013 at 5:24 PM, Davide D'Alto <davide(a)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(a)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(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
7:31 p.m.
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/c0426378671b2e73c9450b43d...
On Wed, Apr 10, 2013 at 5:24 PM, Davide D'Alto <davide(a)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(a)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(a)lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>
>
1:27 a.m.
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(a)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/c0426378671b2e73c9450b43d...
> >
> >
> > On Wed, Apr 10, 2013 at 5:24 PM, Davide D'Alto <davide(a)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(a)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(a)lists.jboss.org
> > >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> > >>
> > >
> > >
>
9:55 a.m.
On 11 avr. 2013, at 01:27, "Davide D'Alto" <davide(a)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(a)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/c0426378671b2e73c9450b43d...
> >
> >
> > On Wed, Apr 10, 2013 at 5:24 PM, Davide D'Alto <davide(a)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(a)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(a)lists.jboss.org
> > >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> > >>
> > >
> > >
3:11 p.m.
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/2dd6bd214d7a1970047310286ef...
Native query with EntityManagert:
https://github.com/DavideD/hibernate-ogm/blob/2dd6bd214d7a1970047310286ef...
On Thu, Apr 11, 2013 at 8:55 AM, Emmanuel Bernard <emmanuel(a)hibernate.org>wrote:
On 11 avr. 2013, at 01:27, "Davide D'Alto" <davide(a)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(a)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/c0426378671b2e73c9450b43d...
> >
> >
> > On Wed, Apr 10, 2013 at 5:24 PM, Davide D'Alto <davide(a)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(a)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(a)lists.jboss.org
> > >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> > >>
> > >
> > >
>
4021
days inactive
4030
days old
9 comments
4 participants
participants (4)
-
Davide D'Alto -
Emmanuel Bernard -
Guillaume SCHEIBEL -
Sanne Grinovero