Comments on: Hibernate never stops surprising me http://www.gmarwaha.com/blog/2010/02/28/hibernate-never-stops-surprising-me/ Ganesh\ Wed, 08 Sep 2010 08:45:02 +0000 http://wordpress.org/?v=2.9.2 hourly 1 By: Kalyan Dasika http://www.gmarwaha.com/blog/2010/02/28/hibernate-never-stops-surprising-me/comment-page-1/#comment-79967 Kalyan Dasika Fri, 03 Sep 2010 19:11:51 +0000 http://www.gmarwaha.com/blog/?p=141#comment-79967 We started our model with a similar approach few years back.. (Address as a component) and then realized we started adding entities like Clinic (has Address) and then we also had to support User to have multiple addresses (moved to new location and as per regulations you keep a list of old address on profile) .. so the Address evolved from a component to an Entity. So a normalized data model would return an Address object ( and not null even if it is undesired) though all the fields are null. If it is a valid condition to be in or not depends on how you handle the use case. We started our model with a similar approach few years back.. (Address as a component) and then realized we started adding entities like Clinic (has Address) and then we also had to support User to have multiple addresses (moved to new location and as per regulations you keep a list of old address on profile) .. so the Address evolved from a component to an Entity. So a normalized data model would return an Address object ( and not null even if it is undesired) though all the fields are null. If it is a valid condition to be in or not depends on how you handle the use case.

]]> By: Bill Smythe http://www.gmarwaha.com/blog/2010/02/28/hibernate-never-stops-surprising-me/comment-page-1/#comment-79263 Bill Smythe Sat, 28 Aug 2010 19:08:22 +0000 http://www.gmarwaha.com/blog/?p=141#comment-79263 This references Mr. King's terminology when responding to users of the application he is partially responsible for. Terms such as 'stupid', 'meaningless', 'nonsense', etc are quite unprofessional. This is not a good way to represent what is a very good argument by those in favor of empty obj elements over a null (no obj?). If it causes users issues and wasted time, then add a switch that allow them to CHOOSE what is returned - the theoretical tirade is not only unprofessional, but immature. If Stephen had an issue with this concept and wasted hours trying to figure out why, then there are hundreds if not thousands of other devs who wasted that time also. This is not a theoretical issue as much as it is a feature desired by users - regardless of how many persons voted for a particular improvement on a site that I hadn't heard of until now - I use apps that behave in ways I do not expect, and it usually results in wasted time trying to figure out the 'logic' that differs from mine - right or wrong. Gavin, get over it - It is more important that 'your' app behaves as expected so developers are not wasting time just to get to an 'aha' moment. Yes, you are probably very brilliant, but that doesn't make me any money if I do not get expected results from your product. Thanks Ganesh for hosting this site! Degrading terms aside, nice theoretical discussion! Bill This references Mr. King’s terminology when responding to users of the application he is partially responsible for.

Terms such as ’stupid’, ‘meaningless’, ‘nonsense’, etc are quite unprofessional. This is not a good way to represent what is a very good argument by those in favor of empty obj elements over a null (no obj?).

If it causes users issues and wasted time, then add a switch that allow them to CHOOSE what is returned – the theoretical tirade is not only unprofessional, but immature.

If Stephen had an issue with this concept and wasted hours trying to figure out why, then there are hundreds if not thousands of other devs who wasted that time also.

This is not a theoretical issue as much as it is a feature desired by users – regardless of how many persons voted for a particular improvement on a site that I hadn’t heard of until now – I use apps that behave in ways I do not expect, and it usually results in wasted time trying to figure out the ‘logic’ that differs from mine – right or wrong.

Gavin, get over it – It is more important that ‘your’ app behaves as expected so developers are not wasting time just to get to an ‘aha’ moment. Yes, you are probably very brilliant, but that doesn’t make me any money if I do not get expected results from your product.

Thanks Ganesh for hosting this site! Degrading terms aside, nice theoretical discussion!

Bill

]]> By: ghd http://www.gmarwaha.com/blog/2010/02/28/hibernate-never-stops-surprising-me/comment-page-1/#comment-76729 ghd Fri, 30 Jul 2010 05:36:09 +0000 http://www.gmarwaha.com/blog/?p=141#comment-76729 Thanks ! wansantg2zxy. Thanks ! wansantg2zxy.

]]> By: official australia uggs http://www.gmarwaha.com/blog/2010/02/28/hibernate-never-stops-surprising-me/comment-page-1/#comment-76671 official australia uggs Thu, 29 Jul 2010 09:49:37 +0000 http://www.gmarwaha.com/blog/?p=141#comment-76671 you are great to post this for us, thanks a lot. you can have a look at the cheap ugg boots. you are great to post this for us, thanks a lot. you can have a look at the cheap ugg boots.

]]> By: Ed http://www.gmarwaha.com/blog/2010/02/28/hibernate-never-stops-surprising-me/comment-page-1/#comment-76580 Ed Wed, 28 Jul 2010 10:42:04 +0000 http://www.gmarwaha.com/blog/?p=141#comment-76580 What about if a component contains an empty collection? Collections don't follow the hibernate null semantics, so all the fields in my component are never all null, so it will always exists :(... And I want it to be null also if it contains an empty collection. Suppose that the Address contains a some collection of logging about he delivered mail at that address. I think the component address should be null also if this collection is null, not ?... I also posted a question about this in the forum: https://forum.hibernate.org/viewtopic.php?f=1&t=1006066 What about if a component contains an empty collection?

Collections don’t follow the hibernate null semantics, so all the fields in my component are never all null, so it will always exists :( … And I want it to be null also if it contains an empty collection.

Suppose that the Address contains a some collection of logging about he delivered mail at that address.
I think the component address should be null also if this collection is null, not ?…
I also posted a question about this in the forum:
https://forum.hibernate.org/viewtopic.php?f=1&t=1006066

]]> By: daggerrz http://www.gmarwaha.com/blog/2010/02/28/hibernate-never-stops-surprising-me/comment-page-1/#comment-76076 daggerrz Tue, 20 Jul 2010 10:05:34 +0000 http://www.gmarwaha.com/blog/?p=141#comment-76076 Hoping to resurrect this interesting thread. We're having issues similar to Stephen, i.e. binding Wicket input fields to expressions like "customer.address.postalCode". I agree with Gavin's points on null semantics and believe that if we _really_ want to always ensure that getAddress returns an address, this should be done in the setter. One point that Stephen mentioned, and I think got lost, is the fact that Hibernate's dirty checking flags a soon-to-be-null address component field as dirty. In other words, if the customer instance is loaded with null address, the address accessor (yeah, I guess it has side-effects) initializes a new address instance when rendering the customer's address (OpenSessionInView) and the customer will be flushed back to the database. The address fields to not change, but auditing status will. So the question is, wouldn't it be reasonable for Hibernate to ensure that the address component really has a persistable state change in order to flag it as dirty? IMO, this would not break the null semantics (rather strengthen it) and at the same time solve our and Stephen's problems. It might have a slight performance impact, but probably only for systems that would rely on this feature. Hoping to resurrect this interesting thread. We’re having issues similar to Stephen, i.e. binding Wicket input fields to expressions like “customer.address.postalCode”. I agree with Gavin’s points on null semantics and believe that if we _really_ want to always ensure that getAddress returns an address, this should be done in the setter.

One point that Stephen mentioned, and I think got lost, is the fact that Hibernate’s dirty checking flags a soon-to-be-null address component field as dirty. In other words, if the customer instance is loaded with null address, the address accessor (yeah, I guess it has side-effects) initializes a new address instance when rendering the customer’s address (OpenSessionInView) and the customer will be flushed back to the database. The address fields to not change, but auditing status will.

So the question is, wouldn’t it be reasonable for Hibernate to ensure that the address component really has a persistable state change in order to flag it as dirty? IMO, this would not break the null semantics (rather strengthen it) and at the same time solve our and Stephen’s problems. It might have a slight performance impact, but probably only for systems that would rely on this feature.

]]> By: official australia uggs http://www.gmarwaha.com/blog/2010/02/28/hibernate-never-stops-surprising-me/comment-page-1/#comment-75877 official australia uggs Sat, 17 Jul 2010 07:36:42 +0000 http://www.gmarwaha.com/blog/?p=141#comment-75877 you are great to do this for us, thanks a lot. you can have a look at the [url]http://www.ugg-sale.biz [/url] you are great to do this for us, thanks a lot. you can have a look at the [url]http://www.ugg-sale.biz [/url]

]]> By: ugg store http://www.gmarwaha.com/blog/2010/02/28/hibernate-never-stops-surprising-me/comment-page-1/#comment-75079 ugg store Fri, 02 Jul 2010 06:31:04 +0000 http://www.gmarwaha.com/blog/?p=141#comment-75079 well done,thanks for sharing. well done,thanks for sharing.

]]> By: charly http://www.gmarwaha.com/blog/2010/02/28/hibernate-never-stops-surprising-me/comment-page-1/#comment-72038 charly Wed, 12 May 2010 02:16:39 +0000 http://www.gmarwaha.com/blog/?p=141#comment-72038 I have one fix: if your framework is unwilling to listen to your needs, stop using it. Try iBatis. I have one fix: if your framework is unwilling to listen to your needs, stop using it. Try iBatis.

]]> By: izle http://www.gmarwaha.com/blog/2010/02/28/hibernate-never-stops-surprising-me/comment-page-1/#comment-70769 izle Fri, 16 Apr 2010 13:34:17 +0000 http://www.gmarwaha.com/blog/?p=141#comment-70769 Hibernate already has waaaay too many switches. If I had my time again I would remove features, not add them. Hibernate already has waaaay too many switches. If I had my time again I would remove features, not add them.

]]>