Home
Help
Register
Log in

Search

 
   Active Threads  

You are here: Home > LLBLGen Pro > Bugs & Issues> migrating v2.6 to v4.1 camelcase issue
 

Pages: 1
Bugs & Issues
migrating v2.6 to v4.1 camelcase issue
Page:1/1 

  Print all messages in this thread  
Poster Message
Pablo
User



Location:
Sneek
Joined on:
21-Mar-2005 01:17:52
Posted:
81 posts
# Posted on: 19-Nov-2013 10:58:57.  
Hello,
I'm migrating from v2.6 to v4.1
I'm still in the 'database first' world ...

In the database I've got an entity: PMail_Block
In my code I use things like:
PMail_BlockCollection
PMail_BlockEntity

Hoewever, this fails, since the newly generated code has renamed the table names:
Pmail_BlockCollection

I've set the following settings in the project settings to off:
Enforce pascal casing always : off
Make element name pascal casing : off
Remove underscores from element name: off

As a general rule, I'd like the generated code to be as close as possible to the actual fields, names etc from the database.

Any setting I'm not seeing here?
Paul
  Top
Otis
LLBLGen Pro Team



Location:
The Hague, The Netherlands
Joined on:
17-Aug-2003 18:00:36
Posted:
37476 posts
# Posted on: 19-Nov-2013 11:04:50.  
Make sure they're OFF in the project settings. It's likely you looked at the preferences, not the project settings.

The names in the project (viewed in the project explorer), are the ones used in the code generation, there's no name processing during code generation for this.

I just tried with the 3 settings OFF in the project settings and I couldn't reproduce it: FKSideCompoundKey table was reverse engineered as FKSideCompoundKey entity and its ID field and IDField1 field was properly kept as-is with the same name.


Frans Bouma
LLBLGen Pro / ORM Profiler Lead Developer | Blog | Twitter
 
Top
Pablo
User



Location:
Sneek
Joined on:
21-Mar-2005 01:17:52
Posted:
81 posts
# Posted on: 19-Nov-2013 11:22:47.  
Hello Otis, thanks for the swift reply ...

But this is weird ...
I made the setting in the designer.

Project -> settings -> (tree) Conventions -> Element Name Construction ...
and there I find the three checkboxes, which I unchecked.

I then saved the project.
Choose to Refresh Relational Model Data

In the log i see the following entry:
Entity 'Pmail_Block'
    Entity migrated to target 'dbo.PMail_Block'.

which indicated again the lowercase 'm'

hummmm... tompoes verzin een list!

I continued with the following steps:
I deleted all the entities in the designer. Choose refresh again ... now It gave me three options -> option 3 (NOT RECOMMENDED????) is to read the database again ....
No it generated indeed the correct names ...

Thanx!!

small question ... why is option 3 the 'not recommended' option? I'm used to this approach for many years ...?!


  Top
Pablo
User



Location:
Sneek
Joined on:
21-Mar-2005 01:17:52
Posted:
81 posts
# Posted on: 19-Nov-2013 11:29:22.  
Humm ... not solved completely though ...
Now i run into the following fieldname error:

In my code I use: PMail_BlockFields

The generated code contains:
Pmail_BlockFields





  Top
Otis
LLBLGen Pro Team



Location:
The Hague, The Netherlands
Joined on:
17-Aug-2003 18:00:36
Posted:
37476 posts
# Posted on: 19-Nov-2013 11:43:34.  
Pablo wrote:
Hello Otis, thanks for the swift reply ...

But this is weird ...
I made the setting in the designer.

Project -> settings -> (tree) Conventions -> Element Name Construction ...
and there I find the three checkboxes, which I unchecked.

I then saved the project.
Choose to Refresh Relational Model Data

In the log i see the following entry:
Entity 'Pmail_Block'
    Entity migrated to target 'dbo.PMail_Block'.

which indicated again the lowercase 'm'

hummmm... tompoes verzin een list!

Tom Poes: "Dat komt omdat de entity er al is, Pablo!" Wink

the settings are used when you reverse engineer an entity. In v2.6, the names of the fields of the project you converted likely are also not correct already (please check this)

Quote:

I continued with the following steps:
I deleted all the entities in the designer. Choose refresh again ... now It gave me three options -> option 3 (NOT RECOMMENDED????) is to read the database again ....
No it generated indeed the correct names ...

Thanx!!

You mean the dialog where it lists options what to do with the changed relational model data it detects? Or some other dialog?

Quote:

small question ... why is option 3 the 'not recommended' option? I'm used to this approach for many years ...?!

I don't know exactly which options you're referring to...
Frans Bouma
LLBLGen Pro / ORM Profiler Lead Developer | Blog | Twitter
 
Top
Pablo
User



Location:
Sneek
Joined on:
21-Mar-2005 01:17:52
Posted:
81 posts
# Posted on: 19-Nov-2013 12:53:52.  
Otis,

I did not migrate the project file v2.6 using the templates...,
I just ended up creating a new project.

So I'm working with the same database, llblgen 4.1, a fresh new llblgenproject, and the codebase I already had which uses the generated code.

The Choice 3 'Skip export and Refresh' I was talking about is in the dialog 'Relational model data export required' that 'sometimes' pops up after choosing Refresh Relational Model Data from a Database.

I still consider the database first method a 'best practice' ...

anyways ... it starts working again. Deleting the entities in the project, followed by a 'refresh relational data from database' did do the trick for the camelcase issue on entity names and field names.

Thanx sofar ... any new issus that might arise, I'll be back ;-)
Paul








  Top
Pages: 1  


Powered by HnD ©2002-2007 Solutions Design
HnD uses LLBLGen Pro

Version: 2.1.12172008 Final.