Capital Column Names

[GoogleCodeExporter]

What steps will reproduce the problem?

1.I have Column Names in SQL as IQMS , CTQ SIC etc , as they generate to 
entities they become Iqms, Ctq etc, Other Codesmith generated code is 
broken as the Caps are preserved in these templates

2.Its not a show stopper as I can fix by adjusting secondary Templates to 
StringUtil.ToPascalCase()which then matches Plinqo code.

3.Is it possible to add "Maintain Caps" as a property maybe

What is the expected output? What do you see instead?

I see Iqms ,Ctq etc not IQMS CTQ
What version of the product are you using?
Latest ex Codesmith

Please provide any additional information below.

Original issue reported on code.google.com by mike.one...@za.sabmiller.com on 2 Sep 2009 at 1:47

[GoogleCodeExporter]

Once you change the names in the DBML and you regenerate, the changes should be 
preserved permanently.  Does that help answer your question?

Original comment by shannon....@gmail.com on 4 Sep 2009 at 3:58

• Changed state: AwaitingInfo
• Added labels: Framework-PLINQO

[GoogleCodeExporter]

I agree , I could make these and they would perist .

I suppose I'm asking NOT to Pascal Case the Column Names as an option so that 
Capitalised names remain as is , 

Once I knew about it its easy to work around so it too big an issue

Original comment by mike.one...@za.sabmiller.com on 15 Sep 2009 at 6:00

[GoogleCodeExporter]

I am having a similiar problem... I have a primary key column "ID" ... and 
every 
time the Dbml.cst is generated, it becomes "Id" ... even if I go into the DBML 
and 
change the member to "ID" and save the DBML.

It seems if the Member name and the column name (in the db) are the same, it 
removes 
the Member name in the DBML and regenerates to "Id" ... the only way the 
changes in 
the DBML persist during the nexxt Dbml.cst generation ... is if the Member name 
and 
the column name are different, not just case, but like "MyID" column name and I 
rename the Member Name to "ID" in the DBML. So you answer to change the names 
in the 
DBML only work if the names are different from the database.

How do we work around this? By the way, a column in the database "MyID" 
actually 
does persist with the ID capped... just not sure why when the who column name 
is "ID" then you like do a tolower then camelcase... ?

Original comment by t...@troyzarger.com on 16 Sep 2009 at 2:48

[GoogleCodeExporter]

HI 

Exactly the problem I had , I normally am a bit more explicit in naming xxxID 
PK's 
but some slipped through.

The simple answer is in Codesmith ToPascal function 

if you do StringUtil.ToPascalCase("ID") you get Id

If you do it again with MyID you keep MyID , its a funny quirk of how they do 
that 
function. I suppose strictly the Pascal case version should only preserve the 
one 
capitalistion so MyID should be MyId , but I suspect they must have ID as 
special 
case suffix maybe

Cheers
Mike

Original comment by mike.one...@za.sabmiller.com on 16 Sep 2009 at 10:46

[GoogleCodeExporter]

There was a fix in the Nightly Builds recently which fixed this issue for me... 
Blake sent me an email and told me to get latest.... So this may be fixed for 
all... 
please get latest and check.

Original comment by t...@troyzarger.com on 2 Oct 2009 at 7:23

[GoogleCodeExporter]

Did you find out if this was fixed in the nightly builds?

Original comment by shannon....@gmail.com on 6 Oct 2009 at 2:54

[GoogleCodeExporter]

It was partially fixed, meaning I can now edit the DBML and make "Id" become 
"ID" 
and it is retained now... However, it would be nice if that step was not 
needed... 
so my issue is fixed with the ability to edit the column name in the DBML.

Does the ToPascalCase do any toLower() functions?

Original comment by t...@troyzarger.com on 6 Oct 2009 at 3:01

[GoogleCodeExporter]

Are you asking that the table and column names not be altered at all in the 
DBML?

Original comment by shannon....@gmail.com on 23 Oct 2009 at 3:55

[GoogleCodeExporter]

No, if I have a column "MyID" ... it ends up in the DBML after generation 
as "MyID" ... if I have a column called "ID" it ends up in the DBML after 
generation 
as "Id" ... Why does it not toLower the "MyID" but it seems to do that on "ID"?

If my column in the DB is indeed "ID" you must be doing some specialized lowere 
on a 
set of keywords... ID must be a special case since MyID is not touched.

Original comment by t...@troyzarger.com on 23 Oct 2009 at 3:59

[GoogleCodeExporter]

I agree with this request.  When did the pascal naming get added to Plinqo?

We have columns named SSN, VIN, SIR that have now been renamed by the latest 
version
of CodeSmith to Ssn, Vin and Sir.  This is breaks a lot of existing code.  If 
we can
change it in the Dbml and it persists, then that is ok, but we didn't have to 
previously.

Original comment by linuscon...@gmail.com on 26 Oct 2009 at 2:23

[GoogleCodeExporter]

Correct, you can change it in the DBML, but this has been problematic as one 
time 
the DBML ended up getting corrupt and had to regen the DBML and of course, I 
had 
sites breaking because I did not catch every place I needed to fix it, such as 
IP 
instead of Ip ... So yes, we can change it in the DBML, but it would be real 
nice if 
we did not have to do this.

Original comment by t...@troyzarger.com on 26 Oct 2009 at 2:49

[GoogleCodeExporter]

Actually, I've found that changing it in the DBML is not an ideal solution at 
all 
even if the DBML is not getting corrupt.  Here is what happens:

1.  When initially generated, the Dbml looks something like this:
<Column Name="VIN" Member="Vin" Storage="_vIN" Type="System.String"... />

2.  You can rename the Member property to "VIN" which results so:
<Column Name="VIN" Member="VIN" Storage="_vIN" Type="System.String"... />

3.  The next time you regenerate the dbml, for some reason it sees that Name 
and 
Member are the same, so it just gets rid of the Member attribute:
<Column Name="VIN" Storage="_vIN" Type="System.String"... />

4.  Finally, if you regenerate it one more time, it sees that you did not 
override 
the Member attribute, so it applies it's Pascal case naming convention:
<Column Name="VIN" Member="Vin" Storage="_vIN" Type="System.String"... />

And you are back to square one.  

How can I work around this?

Original comment by linuscon...@gmail.com on 26 Oct 2009 at 6:24

[GoogleCodeExporter]

I had this same problem, but they fixed it in a nightly build... Are you 
running the 
latest nightly build?

Original comment by t...@troyzarger.com on 26 Oct 2009 at 6:27

[GoogleCodeExporter]

Hi Troy, I assume..

I'm sorry, I'm a bit of a newbie at this.  I installed the latest CodeSmith 
Tools
using their installer.  Looks like version 5.1.6 Revision 9466.

So, if I want to use their nightly PLINQO build, I pulled that down using SVN.  
How
do I replace the PLINQO templates installed in step1 to the latest nightly 
build?

Thanks for your help.

Original comment by linuscon...@gmail.com on 26 Oct 2009 at 7:06

[GoogleCodeExporter]

Sorry, I meant I downloaded the nightly build zip from here.
http://community.codesmithtools.com/nightly/plinqo/

Original comment by linuscon...@gmail.com on 26 Oct 2009 at 7:11

[GoogleCodeExporter]

I simply extract the ZIP file, save it in one of my project folders (the 
location is 
not too important) .... then simply select "Manage Outputs" and update the .cst 
file 
path with wherever you just saved the extracted zip. Granted, I do all that 
from 
within Visual Studio, so if you are not using Visual Studio integration, you 
will 
have to do what you normally do.

I believe by default you will find them templates located at:

MyDocuments\CodeSmith\Samples\v5.1\Templates\Frameworks

Again, I save them in my /Projects/ .... folder, so it does not matter where 
you put 
them.

Hope this helps.

Original comment by t...@troyzarger.com on 26 Oct 2009 at 7:23

[GoogleCodeExporter]

Thank you.  It does.

Original comment by linuscon...@gmail.com on 26 Oct 2009 at 7:27

[GoogleCodeExporter]

What did I start !!!

I am also getting confused , does this nightly build get around preserving ay 
cpital 
changes to the DBML or does it fix the base capitalisation problem.

Maybe Codesmith could comment ?

Mike

Original comment by mike.one...@za.sabmiller.com on 27 Oct 2009 at 4:58

[GoogleCodeExporter]

There is still and issue with the capitalisation problem, however you can make 
changes in the DBML and they will persist with the latest nightly builds.

Yes, it would be nice if a Codesmith or Plinqo guy could comment on if this 
will be 
fixed.

Original comment by t...@troyzarger.com on 27 Oct 2009 at 1:49

[GoogleCodeExporter]

We will not be able update the ToPascal(the function that alters the text) for 
Items 
like IP becoming Ip because it results in too many issues elsewhere.  The 
update to 
the DBML should only be a one time update and then the changes should be 
maintained 
throughout the life of the project.

As far as organization of the templates within the projects.  The Tracker 
Sample is 
how we normally organized the templates.  We add a templates folder and stick 
the 
version of the templates that the project is using in there.  If we are using 
the 
latest build, we add an svn external that always pulls down the latest updates.

Original comment by shannon....@gmail.com on 27 Oct 2009 at 3:23

• Changed state: Fixed

[GoogleCodeExporter]

Okay, so let's say this can't be changed... can there be a bit added to 
indicate if 
we want to do ToPascal ... meaning, could we turn that feature off?

Original comment by t...@troyzarger.com on 27 Oct 2009 at 5:15

[GoogleCodeExporter]

If we added an option to completely leave the names alone, would that work for 
you?

Original comment by shannon....@gmail.com on 28 Oct 2009 at 3:29

• Changed state: AwaitingInfo

[GoogleCodeExporter]

Yes, in the DBML.cst under "Naming Conventions" add an option: "Pascal Casing" 
which 
has two options ... "Preserve" or "Enforce" ...

Would that make sense?

Original comment by t...@troyzarger.com on 28 Oct 2009 at 3:40

[GoogleCodeExporter]

Or perhaps an Option "Casing" and two options "Preserve" and "Enforce Pascal 
Casing" 
would make more sense.

Original comment by t...@troyzarger.com on 28 Oct 2009 at 3:42

[GoogleCodeExporter]

I agree the leave alone option would work for me , that leaves your naming 
conventions as you chose them in the original Db table

Original comment by mike.one...@za.sabmiller.com on 29 Oct 2009 at 8:28

[GoogleCodeExporter]

Adding this to the backlog.

Original comment by shannon....@gmail.com on 29 Oct 2009 at 3:14

• Changed state: Accepted
• Added labels: Type-Enhancement