Re: [hibernate-dev] Serializable SessionFactory

[Vlad Mihalcea]

Yes, out of the JVM. This PR allows the SF to be serialized to a file, so
the next time we bootstrap, we reload the whole SF from the file instead.

There are many unforeseen issues probably related to this PR and it might
hurt maintenance in the long-run.

For this reason, I'm going to leave the PR open as-is, and investigate
whether we can bootstrap faster by avoiding (cacahing) the DB metadata
retrieving the part.

Vlad

On Wed, Jan 10, 2018 at 7:45 PM, Steve Ebersole  wrote:

> The SessionFactory being Serialized outside the VM?  Because otherwise it
> is already "serializable" via VM serialization hooks
> and org.hibernate.internal.SessionFactoryRegistry.  And I'm not so
> convinced we should support serializing it for "out of" VM use aside from
> what we already do which assumes the new target VM has a similarly named
> SessionFactory in its org.hibernate.internal.SessionFactoryRegistry.
>
> On Wed, Jan 10, 2018 at 11:20 AM Vlad Mihalcea 
> wrote:
>
>> Hi,
>>
>> While reviewing old PRs we have in the ORM project, I stumbled on this one
>> about serializing the SessionFactory.
>>
>> I created a new PR, rebased on top of the current master branch and all
>> tests are passing fine.
>>
>> If anyone wants to take a look, this is the PR:
>>
>> https://github.com/hibernate/hibernate-orm/pull/2107
>>
>> I'm thinking we should integrate it in 5.3.Alpha and stabilize it if there
>> are some unforeseen changes.
>>
>> The only drawback is that, if we allow the SF to be Serializable,
>> upgrading
>> will be much more difficult in case we change object structure.
>> We could make it clear that this might not be supported or use the
>> serialVersionUID to point to Hibernate version: major.minor.patch.
>>
>> The main benefit is that, for a microservices architecture, Hibernate
>> could
>> start much faster this way.
>>
>> Vlad
>> ___
>> 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] Serializable SessionFactory

[Steve Ebersole]

I just don't see how serializing a full SessionFactory to disk is a good
idea.

What do you mean by "avoiding (caching) the DB metadata retrieving the
part"?

On Thu, Jan 11, 2018 at 2:08 AM Vlad Mihalcea 
wrote:

> Yes, out of the JVM. This PR allows the SF to be serialized to a file, so
> the next time we bootstrap, we reload the whole SF from the file instead.
>
> There are many unforeseen issues probably related to this PR and it might
> hurt maintenance in the long-run.
>
> For this reason, I'm going to leave the PR open as-is, and investigate
> whether we can bootstrap faster by avoiding (cacahing) the DB metadata
> retrieving the part.
>
> Vlad
>
> On Wed, Jan 10, 2018 at 7:45 PM, Steve Ebersole 
> wrote:
>
>> The SessionFactory being Serialized outside the VM?  Because otherwise it
>> is already "serializable" via VM serialization hooks
>> and org.hibernate.internal.SessionFactoryRegistry.  And I'm not so
>> convinced we should support serializing it for "out of" VM use aside from
>> what we already do which assumes the new target VM has a similarly named
>> SessionFactory in its org.hibernate.internal.SessionFactoryRegistry.
>>
>> On Wed, Jan 10, 2018 at 11:20 AM Vlad Mihalcea 
>> wrote:
>>
>>> Hi,
>>>
>>> While reviewing old PRs we have in the ORM project, I stumbled on this
>>> one
>>> about serializing the SessionFactory.
>>>
>>> I created a new PR, rebased on top of the current master branch and all
>>> tests are passing fine.
>>>
>>> If anyone wants to take a look, this is the PR:
>>>
>>> https://github.com/hibernate/hibernate-orm/pull/2107
>>>
>>> I'm thinking we should integrate it in 5.3.Alpha and stabilize it if
>>> there
>>> are some unforeseen changes.
>>>
>>> The only drawback is that, if we allow the SF to be Serializable,
>>> upgrading
>>> will be much more difficult in case we change object structure.
>>> We could make it clear that this might not be supported or use the
>>> serialVersionUID to point to Hibernate version: major.minor.patch.
>>>
>>> The main benefit is that, for a microservices architecture, Hibernate
>>> could
>>> start much faster this way.
>>>
>>> Vlad
>>> ___
>>> 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] Serializable SessionFactory

[Sanne Grinovero]

On 11 January 2018 at 12:39, Steve Ebersole  wrote:
> I just don't see how serializing a full SessionFactory to disk is a good
> idea.
>
> What do you mean by "avoiding (caching) the DB metadata retrieving the
> part"?

I'm wondering too. I would be very cautious with that: if the
datasource connection is (temporarily) broken, because for example
Hibernate was restarted, we don't really know which assumptions will
still be true. The metadata is possibly no longer valid.

You can't know for sure if the "development cycle" of the users isn't
including some step which makes changes to the database, or maybe even
updates it. I actually expect this to be common and this would cause a
lot of trouble.

If we're willing to invest to make the ORM bootstrap faster, that's
great but we should work on identifying what is being slow and what
can be done without making it dangerous.

>
> On Thu, Jan 11, 2018 at 2:08 AM Vlad Mihalcea 
> wrote:
>
>> Yes, out of the JVM. This PR allows the SF to be serialized to a file, so
>> the next time we bootstrap, we reload the whole SF from the file instead.
>>
>> There are many unforeseen issues probably related to this PR and it might
>> hurt maintenance in the long-run.
>>
>> For this reason, I'm going to leave the PR open as-is, and investigate
>> whether we can bootstrap faster by avoiding (cacahing) the DB metadata
>> retrieving the part.
>>
>> Vlad
>>
>> On Wed, Jan 10, 2018 at 7:45 PM, Steve Ebersole 
>> wrote:
>>
>>> The SessionFactory being Serialized outside the VM?  Because otherwise it
>>> is already "serializable" via VM serialization hooks
>>> and org.hibernate.internal.SessionFactoryRegistry.  And I'm not so
>>> convinced we should support serializing it for "out of" VM use aside from
>>> what we already do which assumes the new target VM has a similarly named
>>> SessionFactory in its org.hibernate.internal.SessionFactoryRegistry.
>>>
>>> On Wed, Jan 10, 2018 at 11:20 AM Vlad Mihalcea 
>>> wrote:
>>>
 Hi,

 While reviewing old PRs we have in the ORM project, I stumbled on this
 one
 about serializing the SessionFactory.

 I created a new PR, rebased on top of the current master branch and all
 tests are passing fine.

 If anyone wants to take a look, this is the PR:

 https://github.com/hibernate/hibernate-orm/pull/2107

 I'm thinking we should integrate it in 5.3.Alpha and stabilize it if
 there
 are some unforeseen changes.

 The only drawback is that, if we allow the SF to be Serializable,
 upgrading
 will be much more difficult in case we change object structure.
 We could make it clear that this might not be supported or use the
 serialVersionUID to point to Hibernate version: major.minor.patch.

 The main benefit is that, for a microservices architecture, Hibernate
 could
 start much faster this way.

 Vlad
 ___
 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 mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

[hibernate-dev] Bulk delete behavior for collection tables

[Christian Beikov]

Hey,

so HHH-5529  defines a 
feature which I'd like to work on but want to hear opinions first.

Currently, bulk deletes only clear join tables of the affected entity 
type. I guess one could argue that this was done because collection 
table in contrast to join table entries should be bound to the entity 
table lifecycle by using an FK with delete cascading. Or maybe it just 
wasn't implemented because nobody stepped up.

I'd like to fill this gap and implement the deletion of the collection 
table entries, but make that and the join table entry deletion configurable.

Does anyone have anything against that?

Would you prefer a single configuration option for join table and 
collection table clearing? If we enable that option by default, 
collection tables will then be cleared whereas currently users would get 
a FK violation. Don't know if that can be classified as breaking behavior.

Or have two configuration options? Even then, would we enable collection 
table entry deletion by default?

-- 

Mit freundlichen Grüßen,

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

Re: [hibernate-dev] Bulk delete behavior for collection tables

[Gail Badner]

Hi Christian,

I'm pretty sure this was implemented, but that it introduced a regression
and ended up being reverted. I'll try to find the issue so you can see the
code that was used.

Regards,
Gail

On Thu, Jan 11, 2018 at 8:56 AM, Christian Beikov <
christian.bei...@gmail.com> wrote:

> Hey,
>
> so HHH-5529  defines a
> feature which I'd like to work on but want to hear opinions first.
>
> Currently, bulk deletes only clear join tables of the affected entity
> type. I guess one could argue that this was done because collection
> table in contrast to join table entries should be bound to the entity
> table lifecycle by using an FK with delete cascading. Or maybe it just
> wasn't implemented because nobody stepped up.
>
> I'd like to fill this gap and implement the deletion of the collection
> table entries, but make that and the join table entry deletion
> configurable.
>
> Does anyone have anything against that?
>
> Would you prefer a single configuration option for join table and
> collection table clearing? If we enable that option by default,
> collection tables will then be cleared whereas currently users would get
> a FK violation. Don't know if that can be classified as breaking behavior.
>
> Or have two configuration options? Even then, would we enable collection
> table entry deletion by default?
>
> --
>
> Mit freundlichen Grüßen,
> 
> *Christian Beikov*
> ___
> 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] Bulk delete behavior for collection tables

[Gail Badner]

Please see https://hibernate.atlassian.net/browse/HHH-9283.

On Thu, Jan 11, 2018 at 11:43 AM, Gail Badner  wrote:

> Hi Christian,
>
> I'm pretty sure this was implemented, but that it introduced a regression
> and ended up being reverted. I'll try to find the issue so you can see the
> code that was used.
>
> Regards,
> Gail
>
> On Thu, Jan 11, 2018 at 8:56 AM, Christian Beikov <
> christian.bei...@gmail.com> wrote:
>
>> Hey,
>>
>> so HHH-5529  defines a
>> feature which I'd like to work on but want to hear opinions first.
>>
>> Currently, bulk deletes only clear join tables of the affected entity
>> type. I guess one could argue that this was done because collection
>> table in contrast to join table entries should be bound to the entity
>> table lifecycle by using an FK with delete cascading. Or maybe it just
>> wasn't implemented because nobody stepped up.
>>
>> I'd like to fill this gap and implement the deletion of the collection
>> table entries, but make that and the join table entry deletion
>> configurable.
>>
>> Does anyone have anything against that?
>>
>> Would you prefer a single configuration option for join table and
>> collection table clearing? If we enable that option by default,
>> collection tables will then be cleared whereas currently users would get
>> a FK violation. Don't know if that can be classified as breaking behavior.
>>
>> Or have two configuration options? Even then, would we enable collection
>> table entry deletion by default?
>>
>> --
>>
>> Mit freundlichen Grüßen,
>> 
>> *Christian Beikov*
>> ___
>> 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] Should HHH-12150 be fixed in 5.3.0.Beta?

[Gail Badner]

HHH-12150 is currently set to be fixed in 5.3.0. I have some time I can
spend on this. There's another issue involving @MapKeyColumn, HHH-10575.

Should I work on these, or something else for 5.3.0.Beta?
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

[hibernate-dev] replace Pax Exam with Docker

[Brett Meyer]

I'm fed up with Pax Exam and would love to replace it as the 
hibernate-osgi integration test harness.  Most of the Karaf committers 
I've been working with hate it more than I do.  Every single time we 
upgrade the Karaf version, something less-than-minor in hibernate-osgi, 
upgrade/change dependencies, or attempt to upgrade Pax Exam itself, 
there's some new obfuscated failure.  And no matter how much I pray, it 
refuses to let us get to the container logs to figure out what 
happened.  Tis a house of cards.



One alternative that recently came up elsewhere: use Docker to bootstrap 
the container, hit it with our features.xml, install a test bundle that 
exposes functionality externally (over HTTP, Karaf commands, etc), then 
hit the endpoints and run assertions.

Pros: true "integration test", plain vanilla Karaf, direct access to all 
logs, easier to eventually support and test other containers.

Cons: Need Docker installed for local test runs, probably safer to 
isolate the integration test behind a disabled-by-default Maven profile.

Any gut reactions?

OSGi is fun and I'm not at all bitter,

-Brett-

;)


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

Re: [hibernate-dev] HHH-12172 - Bintray v. OSSRH

[Brett Meyer]

Sorry for the late and probably irrelevant response...

We're using an in-house Artifactory instance at a gig and it's been 
trash.  I can't speak to the UI or management end, nor Bintray, but 
Artifactory's platform doesn't seem as polished (can't believe I just 
said that) or stable (can't believe I said that either) as Nexus (what 
is happening).

I use OSSRH for some minor projects and have generally had decent luck 
-- including a few interactions with the support team that went well.  
OSSRH != JBoss Nexus, although I definitely understand the wounds...


On 12/19/17 8:34 AM, Steve Ebersole wrote:
> HHH-12172 is about moving away from the JBoss Nexus repo for publishing our
> artifacts.  There is an open question about which service to use instead -
> Sonatype's OSSRH (Nexus) or JFrog's Bintray (Artifactory).
>
> Personally I think Artifactory is far superior of a UI/platform.  We all
> know Nexus from the JBoss deployment of it, and we have all generally had
> nothing good to say about it.
>
> But I am wondering if anyone has practical experience with either, or knows
> persons/projects tyay do and could share their experiences.  E.g., even
> though I prefer Bintray in almost every regard, I am very nervous that it
> seems next to impossible to get help/support with it.  The same may be true
> with OSSRH - I don't know, hence why I am asking ;)
> ___
> 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