Why don't we add a simplified
cfg.buildSessionFactory();
as well?
I understand the importance of the ServiceRegistry, still many won't
need/understand it: thousands of students would be grateful.
Sanne
On 10 April 2013 02:31, Strong Liu wrote:
> StandardServiceRegistryBuilder builder = n
ci.hibernate.org might appear to be down as I thought the domain name
was applied and so yesterday I had applied the final touches to the
server configuration,
but the domain name resolves only when connected to the Red Hat VPN.
reopened the ticket.. sorry for the confusion: I was connected
yester
There is a cfg.buildSessionFactory() Has been one for nearly 10 years.
It is deprecated (as is the whole Configuration class really when you
get down to it and start talking 5.0). It is the deprecation that
Galder asked about.
On 04/10/2013 04:17 AM, Sanne Grinovero wrote:
> Why don't we add
Ok but why deprecating it?
On 10 April 2013 13:23, Steve Ebersole wrote:
> There is a cfg.buildSessionFactory() Has been one for nearly 10 years. It
> is deprecated (as is the whole Configuration class really when you get down
> to it and start talking 5.0). It is the deprecation that Galder as
Which?
I've just explained why Configuration is considered deprecated.
buildSessionFactory() is physically deprecated mainly as a matter of
timing. What will be 5.0 (metamodel branch) was always intended to be
4.0 actually. But timing caused that to not happen exactly as I
wanted. It is the
As an experiment I've added a method to the mongodb provider:
MongoDBDatastoreProvider#(Session session, String sqlString, Class
entityType)
With this method it is possible to execute a native query like "{ $query :
{ author : 'Oscar Wilde' }, $orderby : { name : 1 } }" that will return a
MongoDBOg
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 wrote:
> As an experiment I've added a method to the mongodb provider:
> MongoDBDatastoreProvider#(Session session, Str
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
> 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
