hibernate mysql date ClassCastException September 27, 2006
Posted by javafoo in hibernate, javanotes, mysql.1 comment so far
java.lang.ClassCastException
[java] at org.hibernate.type.DateType.deepCopyNotNull(DateType.java)
[java] at org.hibernate.type.NullableType.deepCopy(NullableType.java)
Does this look familiar. This happens when you define a java.util.Date field in the POJO and try to map it to a mysql ‘date’ datatype. This happens because a ‘date’ datatype represents only the date part and does not include the time part in mysql world, whereas java.util.Date is date+time. Although in Oracle and DB2 and probably other databases a date datatype is actually date+time. If the corresponding field is defined as a ‘datetime’ type in mysql then you should be fine. Also when using hibernate cfg doclet to create the database schemas do not explicitly say type=”date”, let reflection take care of it. Otherwise doclet will map it to date datatype for mysql, which will cause you this grief, leave it to doclet and it will correctly map it to datetime.
Struts mapping actions September 21, 2006
Posted by javafoo in javanotes, struts basic.1 comment so far
In this latest project of mine I was thinking about the various ways to map struts actions. I had done this, a couple of different ways and was wondering if there was a classification out there. And sure enough someone had already done this and instead of paraphrasing, I will just provide the link, here at TSS. Another thing/caveat about using named form-beans accross actions For ex, in your struts-config.xml, if you have a form-bean:
<form-bean name=”xyzForm” type=”package.web.XYZForm” />
and you want to use the same form accross two actions:
<action path=”/processAction” type=”package.web.action.ProcessAction”
parameter=”process”
name=”xyzForm” validate=”true”…..
<action path=”/displayAction” type=”package.web.action.DisplayAction”
parameter=”display”
name=”xyzForm” validate=”false”….
Notice here, I am using the same named form-bean for two actions, in the display action I don’t want to validate the form, but in the process action I want to validate the form. In this case I was in for a surprise, the validate=”true” wasn’t working for the process action. This is because the form params are set only once per form-bean. To overcome this, define two different named form-beans of the same type or if you still want to reuse the form-bean, set validate to true for both actions and within the validate method, based on a parameter decide if you want to validate or not.
Capturing n-to-n relationships, Hibernate etc. September 18, 2006
Posted by javafoo in ER - Entity Relationship, OOAD, hibernate, javanotes.add a comment
So I was trying to capture a one-to-one relationship in Hibernate. I really started thinking about n-to-n relationships and how you can get confused as to where the foreign key goes. I came up with this thumb rule if you have a one-to-many or a many-to-one realtionship the foreign key column id always goes into the “many” end. For ex: I have a one-to-many relationship between Order and OrderLineItem. Since the OrderLineItem is the many end, it will end up holding the Order_id field. So what happens when there is a many-to-many relationship, in that case you have a link table which will hold the primary key ids of both the objects as foreign keys.
Going back to the one-to-one problem, the hibernate config task was not adding the foreign key id, so as a work around I changed it to many-to-one. When I found that it was already mentioned on the hibernate site:
There are two varieties of one-to-one association:
- primary key associations
- unique foreign key associations
So I had effectively done option 2.
Also when creating one-to-many relationships there is a caveat. I was running into constraint violations and found this on the hibernate site: “If the <key> column of a <one-to-many> association is declared NOT NULL, Hibernate may cause constraint violations when it creates or updates the association. To prevent this problem, you must use a bidirectional association with the many valued end (the set or bag) marked as inverse="true".” or do away with all foreign key constraints, I opted for the second option.
If only we spend more time on reading documentation. But there’s no better way than learning from mistakes and then struggling to solve them and finally solving them and then realizing that it was already documented. 
Hello world! September 18, 2006
Posted by javafoo in javanotes.add a comment
That’s the way most of us started our first Java program.
Well I had a lot of “Hello World” moments with Java and seemed to be stuck in second gear for a couple of years. It was just something I had to know, since it was sort of the coolest thing since sliced bread. And friends and acquaintances who worked in Java technologies, looked down upon us lowly structured programming types. Then suddenly the company I worked for, decided to jump on the Java/J2EE bandwagon. All hell broke lose, there were rumours of downsizing us and only having a small maintenance team to manage the legacy system and employing new people to work on developing a new J2EE based system. There was downsizing, some of us were spared and even given an opportunity to upgrade ourselves. But there was a catch, there would be no formal training, we would have to prove our mettle by learning it on the job. So from ‘Hello World’, I was thrown at working on a full fledged J2EE system. I think that’s when we really learn and learn faster, under pressure. We were given step fatherly treatment for a while, the new J2EE kids on the block were the pampered ones. With the latest laptops, their xp programming, their uml diagrams and OO design patterns, we were in awe of these demi gods. But slowly, painfully things fell into place. A side effect of this was that there was not much time to really understand things or organize the knowledge.
Once the job pressure lightened or rather I learned to live with it, I decided to go to school for a Masters degree and I specialized in OOAD (Object Oriented Analysis and Design). That helped a lot, gave me mandatory study time and the project/homework helped me to take a step back and really learn things.
About last year I had started this blog: Common Knowledge in Java which was, sort of a naiive attempt to document a few notes, observations, gripes, struggles, musings and experiences in my trysts with developing Java/J2EE applications, going through interviews in that field etc. This may be common,trivial knowledge, but I just created it to sort of act as a repository for me. If someone else finds it useful, good for them. If someone wants to belittle this or thinks, “well this is sort of basic, you should already know that”, good for them too. But remember, consciously or unconsciously there are times when we do things without thinking and miss out on something really basic. So this is what I am hoping to do, document some eureka moments of mine.
