Mailing-List: contact dev-help@openjpa.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@openjpa.apache.org
Received-SPF: pass (athena.apache.org: domain of jamin.short@gmail.com
 designates 64.233.166.182 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=beta;
        h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=ELDLHdFdoSzylAY4Uuhd2wIMnDXPWWPoKBWKOWht1HKDMYr/ylBKQ8ZWSEVYhpF2GSielTnXivZ6aL+tUxcC2QaFM91ngb53m81Oc5eK30fR4PuoLrRfuryb72Uiq6yQ42vzRHTqIOw+V3hWGGqItMLju4fiPLRHdnTbDAKAxRI=
Message-ID: <86aa493a0711010227h6bb910b9tf772eb855f1be7c7@mail.gmail.com>
Date: Thu, 1 Nov 2007 09:27:34 +0000
From: "ben short" <jamin.short@gmail.com>
To: "Patrick Linskey" <plinskey@gmail.com>
Subject: Re: Automatically removing member variable prefix when naming
 columns.
Cc: dev@openjpa.apache.org
In-Reply-To: <7262f25e0710311713i531878e1r8bac700f3f1e7d1b@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <86aa493a0710250319w29ebc9f4u13faf1e2db35fe18@mail.gmail.com>
	 <7262f25e0710300755w647849f5k8218d96c38048885@mail.gmail.com>
	 <86aa493a0710301454v57c8c4b3sf875748faa4d1edc@mail.gmail.com>
	 <7262f25e0710301533i4b1cc199h5053e55739b7bc76@mail.gmail.com>
	 <86aa493a0710301543y5b7d053dsb8c827afd34af81c@mail.gmail.com>
	 <7262f25e0710301614k5c370cbfkcb20c025b6e98564@mail.gmail.com>
	 <86aa493a0710301627l53d670efo26800fb5ff44d95e@mail.gmail.com>
	 <7262f25e0710301712l4120292fo3527068eb9139d62@mail.gmail.com>
	 <86aa493a0710311550y498d6194ybf91b945b501219c@mail.gmail.com>
	 <7262f25e0710311713i531878e1r8bac700f3f1e7d1b@mail.gmail.com>

Thanks for that Patrick.

Yes I altered the code to remove the Hungarian notation from the index
names, which didn't call correctName().

I'll have ago at getting a debug session running tonight and see if I
cant track down this issue, before I post the patch.

Regards

Ben

On 11/1/07, Patrick Linskey <plinskey@gmail.com> wrote:
> Hi,
>
> (Moving to dev list since this is becoming more dev-related than user-related.)
>
> I'm making some guesses about what your code is doing, but my
> suspicion is that you've done what I suggested and overridden
> correctName(). The ordering of the words in the SQL version of that
> name looks a little suspect; I'd guess that the code is going through
> a different pathway for constructing names for foreign keys in
> relations.
>
> I'd guess that somewhere, the code is not calling correctName() in one
> of those methods. Alternately, maybe the problem is is the
> getTableName() method, which seems to grab the field mapping's name
> and use it in the computation of table names for join tables without
> using correctName() first. Maybe this name then gets incorporated into
> the foreign key col name.
>
> The thing is, the field mapping's name is used directly in a lot of
> places (via FieldMapping.getName()), and that needs to remain as the
> name of the field itself. This is a bit unfortunate, since it makes it
> harder to have just one place to put the code that would do the
> translation for all fields. I believe, however, that the
> MappingDefaults stuff is appropriately designed to make it possible to
> do this, even if we need to catch a few more cases in
> MappingDefaultsImpl.
>
> If you can post a patch somewhere, I can help take a look at some of
> the cases that are failing to be caught.
>
> -Patrick
>
> On Oct 31, 2007 3:50 PM, ben short <jamin.short@gmail.com> wrote:
> > Hi Patrick,
> >
> > Im struggling to find out why field  m_clzFooBar6 of the
> > HungarianNotationFields class does not get it name changed. The
> > classes and the sql executed follows.
> >
> > @Entity
> > public class HungarianNotationFields
> >     {
> >     private String mFooBar1;
> >
> >     private String strFooBar2;
> >
> >     private Integer intFooBar3;
> >
> >     private Long lgFooBar4;
> >
> >     private int m_intFooBar5;
> >
> >     @ManyToOne(targetEntity = OtherClass.class)
> >     private OtherClass m_clzFooBar6;
> >     }
> >
> > @Entity
> > public class OtherClass
> >     {
> >     @Id
> >     private Integer m_intBarFoo1;
> >     }
> >
> > CREATE TABLE HungarianNotationFields (ID BIGINT NOT NULL, FOOBAR3
> > INTEGER, FOOBAR4 BIGINT, FOOBAR1 VARCHAR(255), FOOBAR5 INTEGER,
> > FOOBAR2 VARCHAR(255), m_clzFooBar6_BARFOO1 INTEGER, PRIMARY KEY (ID));
> >
> > CREATE TABLE OtherClass (BARFOO1 INTEGER NOT NULL, PRIMARY KEY (BARFOO1));
> >
> > Any Idea why this might be?
> >
> > Regards
> >
> > Ben
> >
> >
> > On 10/31/07, Patrick Linskey <plinskey@gmail.com> wrote:
> > > Backing state for MappingDefaults.defaultMissing():
> > >
> > > Whether to fill in missing mapping information at runtime with the
> > > default values supplied by this plugin. A value of false means that
> > > all mapping information must be present at runtime.
> > >
> > > -Patrick
> > >
> > > On Oct 30, 2007 4:27 PM, ben short <jamin.short@gmail.com> wrote:
> > > > In the MappingDefaultsImpl class there is a property _defMissing, any
> > > > idea what thats for?
> > > >
> > > >
> > > > On 10/30/07, Patrick Linskey <plinskey@gmail.com> wrote:
> > > > > Cool. FYI, we end up putting most of our test cases in
> > > > > openjpa-persistence-jdbc, for bootstrapping reasons.
> > > > >
> > > > > -Patrick
> > > > >
> > > > > On Oct 30, 2007 3:43 PM, ben short <jamin.short@gmail.com> wrote:
> > > > > > Hi Patrick,
> > > > > >
> > > > > > I managed to get it going... I was trying to get idea to create the
> > > > > > project from the pom. As you say using mvn idea:idea works much
> > > > > > better.
> > > > > >
> > > > > > Thanks
> > > > > >
> > > > > > Ben
> > > > > >
> > > > > >
> > > > > > On 10/30/07, Patrick Linskey <plinskey@gmail.com> wrote:
> > > > > > > I use IDEA mostly.
> > > > > > >
> > > > > > > I set things up initially with mvn at the command line, and then ran
> > > > > > > mvn idea:idea to build project files. But the craziness around the jjt
> > > > > > > and javacc mvn plugins meant that I needed to manually modify
> > > > > > > something to get the project files just so.
> > > > > > >
> > > > > > > I do compilations from IDEA directly, not via the mvn integration. And
> > > > > > > I use TeamCity to fire off remote tests and checkins.
> > > > > > >
> > > > > > > -Patrick
> > > > > > >
> > > > > > > On Oct 30, 2007 2:54 PM, ben short <jamin.short@gmail.com> wrote:
> > > > > > > > What IDE do you guys use, as im having a hell of a time getting it to
> > > > > > > > work with idea 7
> > > > > > > >
> > > > > > > >
> > > > > > > > On 10/30/07, Patrick Linskey <plinskey@gmail.com> wrote:
> > > > > > > > > Best thing to do is create a JIRA and attach the diff (svn diff >
> > > > > > > > > openjpa-<jiranumber>.patch). If you don't have a JIRA account, let me
> > > > > > > > > know; I'll create an issue for you.
> > > > > > > > >
> > > > > > > > > -Patrick
> > > > > > > > >
> > > > > > > > > On Oct 30, 2007 2:07 AM, ben short <jamin.short@gmail.com> wrote:
> > > > > > > > > > OK I'll give it ago. I assume that you'll need a patch of the changes
> > > > > > > > > > I make. Where is the best place to send it once I'm done?
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > On 10/29/07, Patrick Linskey <plinskey@gmail.com> wrote:
> > > > > > > > > > > Hi,
> > > > > > > > > > >
> > > > > > > > > > > You can do this by providing your own MappingDefaults implementation
> > > > > > > > > > > (via the openjpa.MappingDefaults property). You'll probably want to
> > > > > > > > > > > extend PersistenceMappingDefaults and override correctName(), to stay
> > > > > > > > > > > in line with the rest of the JPA defaulting rules and to simplify the
> > > > > > > > > > > implementation.
> > > > > > > > > > >
> > > > > > > > > > > Alternately, you could improve MappingDefaultsImpl and contribute the
> > > > > > > > > > > change to OpenJPA. Such an improvement might look like so:
> > > > > > > > > > >
> > > > > > > > > > > 1. add a new setter/getter pair called 'removeHungarianNotation' (a
> > > > > > > > > > > boolean) or 'removeLeadingPrefixes' (a list of strings).
> > > > > > > > > > >
> > > > > > > > > > > 2. implement logic in MappingDefaultsImpl.correctName() to either
> > > > > > > > > > > guess about hungarian-notation trimming or to remove the prefixes
> > > > > > > > > > > identified in 'removeLeadingPrefixes'.
> > > > > > > > > > >
> > > > > > > > > > > 3. write a test case that that extends SingleEMFTestCase and looks
> > > > > > > > > > > something like so:
> > > > > > > > > > >
> > > > > > > > > > > public TestColumnNameTruncation extends SingleEMFTestCase {
> > > > > > > > > > >     public void setUp() {
> > > > > > > > > > >         setUp(HungarianNotationFields.class, CLEAR_TABLES,
> > > > > > > > > > >             "openjpa.MappingDefaults", "RemoveLeadingPrefixes=\"m,_\"");
> > > > > > > > > > >     }
> > > > > > > > > > >
> > > > > > > > > > >     public void testColumnNameTruncation() {
> > > > > > > > > > >         ClassMapping cm = (ClassMapping) JPAFacadeHelper.getMetaData(emf,
> > > > > > > > > > >             HungarianNotationFields.class);
> > > > > > > > > > >         // check that the associated FieldMappings in cm have the
> > > > > > > > > > > right column names
> > > > > > > > > > >     }
> > > > > > > > > > > }
> > > > > > > > > > >
> > > > > > > > > > > -Patrick
> > > > > > > > > > >
> > > > > > > > > > > On 10/25/07, ben short <jamin.short@gmail.com> wrote:
> > > > > > > > > > > > Hi,
> > > > > > > > > > > >
> > > > > > > > > > > > I name my class member variables (fields) with the prefix m, such as
> > > > > > > > > > > > mId. Is it possible to tell OpenJPA to create the table columns
> > > > > > > > > > > > without the m prefix?
> > > > > > > > > > > >
> > > > > > > > > > > > I know this can be done using the @Column annotation, but it would be
> > > > > > > > > > > > nice to be able to set a global flag, like I think you can with
> > > > > > > > > > > > hibernate.
> > > > > > > > > > > >
> > > > > > > > > > > > Regards
> > > > > > > > > > > >
> > > > > > > > > > > > Ben
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > --
> > > > > > > > > > > Patrick Linskey
> > > > > > > > > > > 202 669 5907
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > --
> > > > > > > > > Patrick Linskey
> > > > > > > > > 202 669 5907
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > --
> > > > > > > Patrick Linskey
> > > > > > > 202 669 5907
> > > > > > >
> > > > > >
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Patrick Linskey
> > > > > 202 669 5907
> > > > >
> > > >
> > >
> > >
> > >
> > > --
> > > Patrick Linskey
> > > 202 669 5907
> > >
> >
>
>
>
> --
> Patrick Linskey
> 202 669 5907
>