The problem here is that java.util.Date holds an actualy time/date. If you don't map it to TIMESTAMP, then you have a dataloss.
If you want a real SQL DATE field, then use java.sql.Date (which is a java.util.Date with the time suppressed) I think it would be bad policy to make the default data storage mechanism lose data upon storage. Think about: Date d = new Date(); ejb = Home.create(d); if (ejb.getDate().equals(d))// this is true doSomething(); else doSomethingElse(); ejb = Home.find(PKOFEJB); if (ejb.getDate().equals(d))// no longer true since you dropped time doSomething(); else doSomethingElse(); So you would, in effect, be breaking application logic. The user would expect both .equals() to be true. Or does PostgreSQL DATE/TIMESTAMP exactly the same? I know oracle will drop the time portion if the column type is DATE. -David On Tue, 12 Feb 2002, Adam Heath wrote: > On Tue, 12 Feb 2002, Dain Sundstrom wrote: > > > This is for anyone who knows Postgres out there, > > > > There is a patch at sf that suggest adding the following mapping: > > > > <mapping> > > <java-type>java.util.Date</java-type> > > <jdbc-type>TIMESTAMP</jdbc-type> > > <sql-type>TIMESTAMP</sql-type> > > </mapping> > > > > There is currently no mapping for java.util.Date, but there is a mapping > > for java.sql.Date, which is: > > > > <mapping> > > <java-type>java.sql.Date</java-type> > > <jdbc-type>DATE</jdbc-type> > > <sql-type>DATE</sql-type> > > </mapping> > > I prefer the latter. My reasoning, is that if java.util.Date is mapped to > TIMESTAMP, then how does someone make a DATE in the database? > > They could use java.sql.Timestamp to accomplish that. > > This is what I have done for my debian packages. > _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
