Re: [hibernate-dev] GSoC 2016: Congratulations, your proposal with JBoss Community has been accepted!

[andrea boriero]

Welcome Mincong!!!

On 22 April 2016 at 22:20, Mincong Huang  wrote:

> Hi everybody,
>
> Thanks for accepting my application of GSoC !! Really excited to having
> chance to work the hibernate team. I'm so happy to see this email. It's
> just
> like a dream, can't believe it is true !! Thanks for choosing me. I'll try
> my
> best to accomplish this mission !! Happy coding and good night :-)
>
> Cheers,
> Mincong
>
> On Fri, Apr 22, 2016 at 9:25 PM, Google Summer of Code <
> summerofcode-nore...@google.com> wrote:
>
> > [image: Google Summer of Code]
> >
> > Hi mincongh,
> >
> > Welcome to GSoC 2016!
> >
> > Your proposal Hibernate Search: JSR 352 batch job for re-indexing
> entities
> > <
> https://summerofcode.withgoogle.com/dashboard/student/proposal/5244068401512448/
> >
> > has been accepted!
> >
> > We look forward to seeing the great things you will accomplish this
> summer
> > with JBoss Community.
> >
> > This email contains important information about your participation in
> GSoC
> > this year. Please read it carefully.
> >
> > Over the next month you will take part in the Community Bonding period
> > with your organization. This period is for you to become familiar with
> the
> > organization's code base, version control and other infrastructure. You
> > will be getting to know the community and its practices, as well as
> working
> > with your mentor on milestones for the summer.
> >
> > Complete all of these steps as soon as you can:
> >
> >1. Read the Accepted Student Information
> ><
> https://developers.google.com/open-source/gsoc/help/accepted-students>
> >2. Upload  your tax
> >form *before May 16, 2016 at 19:00 UTC*
> >3. Read the Student Payment Information
> >
> >4. Set up your Payoneer account before May 16, 2016 at 19:00 UTC
> >5. Verify your shipping address, promotional materials, and t-shirt
> >information on your profile
> >.
> >
> > If you have questions about anything in this email, please email the
> > Google GSoC support team at gsoc-supp...@google.com. Don’t email the
> > student list with tax or payment issues.
> >
> > Have a great summer!
> >
> > Google Open Source Programs team
> >
> > This email was sent to mincon...@gmail.com.
> >
> > You are receiving this email because of your participation in Google
> > Summer of Code 2016.
> > https://summerofcode.withgoogle.com
> >
> > To leave the program and stop receiving all emails, you can go to your
> > profile  and
> > request deletion of your program profile.
> >
> > For any questions, please contact gsoc-supp...@google.com. Replies to
> > this message go to an unmonitored mailbox.
> >
> > © 2016 Google Inc., 1600 Amphitheatre Parkway, Mountain View, CA 94043,
> > USA
> >
> ___
> 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

Re: [hibernate-dev] [HSEARCH] Usage of ShardIdentifierProvider

[Gunnar Morling]

2016-04-22 12:55 GMT+02:00 Sanne Grinovero :

> On 21 April 2016 at 18:35, Gunnar Morling  wrote:
> > Hi,
> >
> > As IndexShardingStrategy is deprecated, I thought I'd use
> > ShardIdentifierProvider and friends in new code I write. It's not clear
> to
> > me though, how it's meant to be used.
> >
> > Some questions:
> >
> > * Is it correct that EntityIndexBinding#getShardIdentifierProvider()
> > returns null is sharding is not used for this entity?
>
> Yes, as the javadoc suggests.
>

Ok, thanks; The current comment is rather vague, it should more clearly
state when the return value will be null.

I don't like to return "null"s so if
>
> > I suppose in that
> > case I simply can use EntityIndexBinding.getIndexManagers()[0]?
>
> I'm not understanding how this related to the previous question. What
> are you up to?
>

E.g. look at DefaultBatchBackend. Working on improving batch performance
for the ES backend, I came across the deprecation of IndexShardingStrategy
and wondered what it'd take to get rid of that.

N.B. the intent of the sharding strategies is not to give end users a
> reference to the IndexManagers.
> So the `ShardIdentifierProvider` contract lets people identify the
> target indexes by naming them.
>

The deprecation comment on IndexShardingStrategy says "Use
ShardIdentifierProvider
instead". Are you saying that this cannot be done actually? That's what I
tried: "use SIP" and from the shard name obtain an index manager. But your
next comment below makes me wonder whether that's actually desirable.

>
> > * What's the envisioned way to get the IM for a given shard once I know
> the
> > shard id? I found IndexManagerHolder.getOrCreateIndexManager(), but this
> > expects a *DynamicSharding*EntityIndexBinding, so how would it work for
> > non-dynamic sharding?
>
> The envisioned way is that the user doesn't get a reference to the
> IndexManager,
> what he needs is to identify the indexes - not act on them.
>

See above. I'm confused by the deprecation comment on
IndexShardingStrategy. Right now I don't see how ShardIdentifierProvider
can be used instead.

>
> >
> > It's tough to see how the pieces are meant to fit together, now that
> > IndexShardingStrategy and ShardIdentifierProvider are there. I hope we
> can
> > get rid of the former soon, simplifying the code a bit?
>
> Yes. It has been deprecated for long enough, we could give a shot of
> removing the old one if this helps something you're doing?
>
> I wouldn't remove it yet if it's not in the way of our 5.6 requirements.
>
> BTW the contract "IndexShardingStrategy" is deprecated so that users
> of sharding move to the new API, but that interface still is the
> foundation of the implementation even for dynamic sharding.. it's not
> being removed from internals.
>

Aaah, so are you saying that IndexShardingStrategy is only deprecated for
use by Hibernate Search users, but internally it's not meant to go away?
I.e. it'll just be removed from the public API but will continue to exist
in some "impl" package?

If so, some more explicit comment about the nature of this deprecation
would help :)


> The new contract just enables us to add new shards dynamically, but
> you can see this also as a removal of the previous limitation. The
> high level concept can keep the generic name "index sharding strategy"
> as it's still fitting.
>
> You can see this as a plan to not have users to choose between two
> ways to express the same thing.
>
> Thanks,
> Sanne
>
> >
> > Thanks,
> >
> > --Gunnar
> > ___
> > 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

Re: [hibernate-dev] Various expectation changes in hibernate-core after consolidating hibernate-entitymanager

[Vlad Mihalcea]

Your second email summarizes my thoughts as well. If we can separate the
exception handling in two separate strategies that are defined during
bootstrap (JPA vs Hibernate),
I think that's the way to go.

There so many projects out there that rely on the exception type being
thrown, and changing those would make it very difficult for them to migrate
to this new version.
But that only affects Hibernate-native projects since, for those who have
been using JPA, they already expect the JPA exceptions anyway.

As for the other behavior discrepancies:

1. "calling EntityManager#close on a closed EntityManager should result in an
exception;" - that's a reasonable default and shouldn't cause too much
trouble.
2. "Another change in expectation is in regards to operations outside of a
transaction" - in JPA we can execute queries outside a transaction, but any
write will fail if there is no transactional context, which is reasonable
for me too. If Hibernate allows writes outside of a transactional context,
that's definitely a thing we should not support anyway.
3. "Asking a Session if is contains (Session/EntityManager#contains) a
 non-entity" - we can handle this with the separate exception handler
strategies to retain both JPA and Hibernate behaviors.
4. "Accessing Session/EntityManager#getTransaction.  JPA says that is
only allowed
for JDBC transactions.  Hibernate always allows it." - I'd choose the
Hibernate behavior because I don;t see how it can cause any issue and it's
an enhancement as well.

Vlad





On Sat, Apr 23, 2016 at 5:29 PM, Steve Ebersole  wrote:

> Just realized that I should have mentioned an important plan that helps
> understand the idea behind the "exception handling strategy" route.  I plan
> to keep track of how a SessionFactory was bootstrapped in some fashion.  So
> when it was bootstrapped from EntityManagerFactoryBuilder (which JPA
> bootstrap methods leverage) we'd select the "JPA exception handling"
> strategy impl.  When not, we'd use the "legacy Hibernate exception
> handling" strategy.
>
> On Sat, Apr 23, 2016 at 9:21 AM Steve Ebersole 
> wrote:
>
> > There are a number of "expectation changes" that come about from
> > consolidating hibernate-entitymanger into hibernate-core.  Some we have
> > discussed; some we have not.  Hopefully we can come to a consensus
> regards
> > how to deal with these changes...
> >
> > The first one is different exception types.  We have discussed this
> > before.  For now, in an effort to fix test failures and move forward with
> > developing, I simply changed failing tests to expect the JPA defined
> > exceptions.  I had mentioned, where possible, to to throw a combination
> of
> > the 2 expected exceptions.  Generally this falls into 2 discrete
> categories:
> >
> >
> >1. JPA expects a PersistenceException and we have historically thrown
> >a HibernateException
> >2. JPA expects some form of JDK RuntimeException
> >(IllegalArgumentException, IllegalStateException, etc) and we have
> >historically thrown a HibernateException
> >
> > It is unfortunate that Java does not allow exceptions to be defined by
> > means of interfaces; that's the only "clean" way I see to do this - that
> > would have allowed us to define concrete exception classes that extend
> > PersistenceException, IllegalArgumentException, etc and that implement
> HibernateException.
> >
> >
> > So I see 3 potential solutions (feel free to bring up others).
> >
> >1. Just move to JPA expected exceptions.
> >2. Have HibernateException extend PersistenceException and just not
> >worry about the change in expectation in regards to that second
> category.
> >3. Push exception handling behind a strategy.  This would have to be a
> >pretty specific strategy for very specific cases.
> >
> > The first and second options are pretty self-explanatory and
> > straight-forward so I won't go into detail there.  Just realize that
> these
> > change the expectation for the user.  They'd have to change their code to
> > catch these JPA-defined exceptions.
> > The other option, I see, is to h
> >
> > The third option is perfect in theory, but it is very tedious.  For
> > example, take the case of trying to perform some operation on a closed
> > Session/EntityManager.  Hibernate historically threw a HibernateException
> > here.  JPA says that should result in an IllegalStateException.  So in
> > SessionImpl#checkOpen, when the Session/EntityManager is closed, we'd
> > call out to the strategy to handle that condition.  Even more, Hibernate
> > (historically) and JPA disagree about which methods getting called on a
> > closed Session/EntityManager should lead to an exception.  For example,
> > JPA says calling EntityManager#close on a closed EntityManager should
> > result in an exception; Hibernate historically did not care if you called
> > Session#close on a closed Session.  So that is a special case, and every
> > one of those special cases would have to be exposed