Re: [hibernate-dev] Pleas help with GITHub, how to get new branches into personal fork?

2013-04-09 Thread Demetz, Guenther
Hi Steve,

thank you very much for the prompt answer, got it.

I just created 2 pull-requests for branch 4.2, maybe next week's someone of you 
developers can take a look into... 

https://github.com/hibernate/hibernate-orm/pull/501  testcase and patch 
proposal for HHH-8154
https://github.com/hibernate/hibernate-orm/pull/504  testcase and patch 
proposal for HHH-4294

best regards
Guenther

-Original Message-
From: Steve Ebersole [mailto:steven.ebers...@gmail.com] On Behalf Of Steve 
Ebersole
Sent: Friday, April 05, 2013 3:38 PM
To: Demetz, Guenther
Cc: Hibernate
Subject: Re: [hibernate-dev] Pleas help with GITHub, how to get new branches 
into personal fork?

Create a remote in the clone of your fork that refers to the upstream Hibernate 
repo:

* git remote add upstream git://github.com/hibernate/hibernate-orm.git

fetch the 4.2 branch into your clone:

* git fetch upstream 4.2:4.2

You can choose to push this to your fork or not.  If so (assuming you left that 
remote named "origin"):

* git push origin 4.2:4.2

Do your work...


On 04/05/2013 08:23 AM, Demetz, Guenther wrote:
> Hello hibernate developers,
>
> I want to open a JIRA-Issue and as always I like to provide an according  
> test-case in form of a pull-request.
> I already created pull-requests in past, but now I need  to update/align my 
> fork of hibernate-orm with branch 4.2 which at the time of fork-creation did 
> not exist yet.
> How to do that without destroying my fork first?
> It seems that GitHub does allow maximal one fork per repository. I tried 
> almost everything imaginable without success.
> If someone could give me an advice please..
>
> thanks
> Guenther Demetz
>
> ___
> 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


[hibernate-dev] Correct way to build a session factory?

2013-04-09 Thread Galder Zamarreño
Hi,

Re: 
http://docs.jboss.org/hibernate/orm/4.2/quickstart/en-US/html_single/#hibernate-gsg-tutorial-basic-test

The code there to build a session factory is deprecated, in particular the 
parameter-less buildSessionFactory(), what's the correct way to build a session 
factory? 

I'm doing this for a presentation, hence I want to avoid using deprecated 
methods :)

Cheers,
--
Galder Zamarreño
gal...@redhat.com
twitter.com/galderz

Project Lead, Escalante
http://escalante.io

Engineer, Infinispan
http://infinispan.org


___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev


Re: [hibernate-dev] unique constraint changes

2013-04-09 Thread Brett Meyer
The unique constraint changes are reverted in 4.1.12-SNAPSHOT.

I'm following this discussion up with 
https://hibernate.atlassian.net/browse/HHH-8162.  Any further comments, please 
leave them there.  Thanks!

Brett Meyer
Red Hat Software Engineer, Hibernate

- Original Message -
From: "Brett Meyer" 
To: "Guillaume Smet" 
Cc: "Hibernate" 
Sent: Monday, April 8, 2013 1:37:26 PM
Subject: Re: unique constraint changes

We cannot simply remove unique constraint generation on an update all-together 
-- although you have a good point about the exceptions, many users still rely 
on that functionality.  Instead, let's make it configurable.  A property would 
select from the following:

1.) Update ignores all unique constraints
2.) Update drops *all* unique constraints and re-creates them
3.) Update attempts to (re-)create the unique constraints and ignores any errors

Any other options?  I'd argue that #3 would be the default.  #2 is problematic 
for DBs that have non-mapped constraints.

Brett Meyer
Red Hat Software Engineer, Hibernate

- Original Message -
From: "Guillaume Smet" 
To: "Brett Meyer" 
Cc: "Hibernate" 
Sent: Saturday, April 6, 2013 12:40:27 PM
Subject: Re: unique constraint changes

Hi Brett,

Thanks for following up on this. My comments below.

On Fri, Apr 5, 2013 at 6:44 PM, Brett Meyer  wrote:
> Here's what I'd like to do.  In 4.1.x, all of the unique 
> constraint/index/column changes from HHH-7797 [1] and the random constraint 
> names in HHH-1904 [2] will be reverted.  When we originally started working 
> on them, they weren't intended to be this complex.  We'll cut a new 4.1.x 
> release.

Sounds the best thing to do.

> Regarding the concern brought up in HHH-8092 [3] (constraints re-generated in 
> schema update, even if they exist): Defaulting to unique constraints, as 
> opposed to indexes or unique columns, was the best route and most widely 
> supported.  As discussed, it's difficult and un-reliable to attempt to find 
> existing constraints prior to updating.  And remember that schema generation 
> was never meant to be used for production environments -- supporting every 
> single use case and situation is impossible.

Here is where I don't follow you because "update" mode is very widely
used, especially in development environments but probably also in
production.

My 2 cents:
- You can't have a behaviour where you have a ton of SQL error
messages at each startup. The way it worked before was a better
compromise IMHO: the unique constraints were created only at table
creation. It wasn't perfect but was the best compromise we can find
IMHO, when you are in update mode.
- You can't publish a maintenance release with a major change in the
naming scheme. Releasing it as a 4.2.0 sounds sane. BUT you have to
clearly mention it in the release notes with all the problems it can
cause to the users. And perhaps provide guidance on how to update
without too much pain.

As a long time Hibernate user trying to keep up with the releases to
provide feedback from the field to the Hibernate (and Search) team as
soon as possible (and sometimes fixing bugs), I was quite surprised by
this change and I would have liked to be warned in the release
announcement.

HTH

-- 
Guillaume
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev


Re: [hibernate-dev] Correct way to build a session factory?

2013-04-09 Thread Strong Liu
StandardServiceRegistryBuilder builder = new StandardServiceRegistryBuilder();
StandardServiceRegistry serviceRegistry = builder.build();
cfg.buildSessionFactory(serviceRegistry);

On Apr 9, 2013, at 8:28 PM, Galder Zamarreño  wrote:

> Hi,
> 
> Re: 
> http://docs.jboss.org/hibernate/orm/4.2/quickstart/en-US/html_single/#hibernate-gsg-tutorial-basic-test
> 
> The code there to build a session factory is deprecated, in particular the 
> parameter-less buildSessionFactory(), what's the correct way to build a 
> session factory? 
> 
> I'm doing this for a presentation, hence I want to avoid using deprecated 
> methods :)
> 
> Cheers,
> --
> Galder Zamarreño
> gal...@redhat.com
> twitter.com/galderz
> 
> Project Lead, Escalante
> http://escalante.io
> 
> Engineer, Infinispan
> http://infinispan.org
> 
> 
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

-
Best Regards,

Strong Liu 
http://about.me/stliu/bio



___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev