Perfect, thanks!
Used the following for my build.xml, and got desired results for an MS
SQL 2000 database reverse engineered.
<reversemappingtool
...
typeMap="integer=java.lang.Long,
char=java.lang.String,
tinyint=java.lang.Boolean,
decimal=java.lang.Double,
bigint=java.lang.Long,
timestamp=java.util.Date"
>
If you do not know what the database metadata calls your SQL_TYPES, run
the schematool to generate a schema.xml file -- this will tell you what
the SQL_TYPES are.
Again, thanks for the info, and thanks for implementing this great tool
with the feature!
-D
> -----Original Message-----
> From: Patrick Linskey [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, February 27, 2008 4:28 PM
> To: [email protected]
> Subject: Re: [reversemappingtool] Way to set default object/primitive
> behavior
>
> Hi,
>
> I think that the -typeMap argument to the ReverseMappingTool is what
> you're looking for.
>
> The syntax is a comma-separated list of key-value pairs:
>
> java ReverseMappingTool -typeMap INT=int,VARCHAR2=String ...
>
> I might have the syntax a bit wrong; you might need to specify
> INT=int.class and VARCHAR2=java.lang.String.class, or something along
> those lines, but that should do the trick.
>
> -Patrick
>
> On Wed, Feb 27, 2008 at 8:12 AM, Darren Hartford
<[EMAIL PROTECTED]>
> wrote:
> > Hey all,
> >
> > Been using the OpenJPA to reverse engineer from existing database
> > structures to create DTO and orm.xml files with great success!!!
> >
> >
> >
> > I'm an old middlegen user, but have migrated to OpenJPA. One of
the
> > features in middlegen that I appreciated was defining the default
> > behavior of mapping the SQL type to the Java type.
> >
> >
> >
> > For instance, one project might convert SQL to DTO fields as:
> >
> > SQL_INT - int
> >
> > SQL_LONG - long
> >
> > SQL_DATE - java.sql.Date
> >
> >
> >
> > While another project would be:
> >
> > SQL_INT - java.lang.Long
> >
> > SQL_LONG - java.lang.Long
> >
> > SQL_DATE - java.util.Date
> >
> >
> >
> > Now, I've been getting by with the reverse-customizer.properties
> > approach, but since I need to explicitly define EACH field across
an
> > entire dataset, this is very time consuming.
> >
> >
> >
> > Is there an existing approach that would help with setting default
> > behavior, or is this something that sounds like a reasonable
> enhancement
> > and should be added to JIRA?
> >
> >
> >
> > Thanks,
> >
> > -D
> >
> >
> >
> >
>
>
>
> --
> Patrick Linskey
> 202 669 5907