Home
Help
Register
Log in

Search

 
   Active Threads  

You are here: Home > LLBLGen Pro > Custom Templates> Multiple db schema/catalog, custom template, Group name property
 

Pages: 1
Custom Templates
Multiple db schema/catalog, custom template, Group name property
Page:1/1 

  Print all messages in this thread  
Poster Message
Keiser
User



Location:

Joined on:
21-Apr-2010 11:09:32
Posted:
17 posts
# Posted on: 29-Jan-2015 11:45:38.  
Hi guys,

I have multiple db schema/databases (catalogs), both added to LLBL project, Sql Server
(1) first one is main database and has no group name defined
(2) second one db schema is history database, with defined "HistoryDB"
Property for grouping is set to "AsSeparateProjects" (mainly because of different connection strings).
I'm also using adapter mode and templates defined currently were working fine (I recently added this 2nd schema/group).

Link to screenshots:
LLBL project explorer: http://screencast.com/t/eNF8ULwhrcf
VS project structure: http://screencast.com/t/fhhqzsLeDr

Problems and questions:
1) generation of entities (and the stuff) seems to work fine and files are generated as expected, except DAL layer, SP calls generation code that creates SP calls in the second group although it does not have defined any (might be that templates changed to version 4.0, as they were transfered because of minor changes from previous I think version 2.6)
2) how can I use "group name" in connection string generation
Code:
public static string ConnectionStringKeyName="<[ConnectionStringKeyName]>";

gives me in DataAccessAdapter.cs ( I have 2 as expected in different namespaces) files but both pointing to the same connection key.
Code:

public static string ConnectionStringKeyName="Main.ConnectionString";


I would like to be able to specify "Main.ConnectionString.GroupName" key name if defined group name is different then empty string. As rend result would have 2 connection string keys, each for one group/db/catalog. Am I able to do that somehow?

<[RootNamespace]> property seems to have correct info in (2)

I searched SDK documentation, but didn't found this type of info, also tried with threads of similar content but aslo didn't found useful info.

Regards,
K.

P.S. pardon me for my ignorance if I didn't found existing thread with the same problem Embarrassed
  Top
Walaa
Support Team



Location:

Joined on:
21-Aug-2005 16:03:48
Posted:
14429 posts
# Posted on: 29-Jan-2015 18:00:07.  
Which version of LLBLGen Pro are you using?
Also Designer release date (Help/About)?


  Top
Keiser
User



Location:

Joined on:
21-Apr-2010 11:09:32
Posted:
17 posts
# Posted on: 29-Jan-2015 20:13:51.  
version 4.0 (May 15th, 2013), I have downloaded 4.2 but didn't installed yet. Would new version update resolve things probably?
Any way, today I decided to go the other path and created new project, seems to me this is the easier way to maintain different catalogs. Although I'm just interested how that can be accomplished still (or is it possible at all).

Regards,
K.
  Top
daelmo
Support Team



Location:
Guatemala City
Joined on:
28-Nov-2005 23:35:24
Posted:
8034 posts
# Posted on: 30-Jan-2015 06:07:45.  
AFAIK the {$GroupName} macro (which would be the possible solution here) is not supported in the connection string key name. The designer generates only as many connection strings as different providers you have on your project (i.e. SQLServer, Oracle, etc). So it assumes that different groups connects to the same DB after all.
If you are using multiple catalogs on the same server this is not an issue because each table is connected to the right catalog.

A workaround: if you set the GroupUsage setting to 'separate projects' you could create a DataAccessAdapter subclass that change at the constructor the ConnectionStringKeyName member to your desire connection string key name, for each project. Then you must use that DataAccessAdapter subclass in your own code.

Your workaround is indeed a better choice. The only advantage of having different groups ('as separate projects') over your workaround, is having all the objects 'together' in the same project.


David Elizondo
LLBLGen'ing (articles and code snippets) | linkedin | twitter
 
Top
Keiser
User



Location:

Joined on:
21-Apr-2010 11:09:32
Posted:
17 posts
# Posted on: 30-Jan-2015 10:04:34.  
Thank you on replay.

I had similar thing already (refering to AccessAdapter) but connecting to the same DB schema, and this is understandable.

But having GroupName constant provided in code generation would extend templating much further. (I could acomplish my thing w/o problem)
In one scenario I thought, what about if I could also select schema/group upon which I would like to execute task ( and I can only select DB server, or all of them).
Maybe I don't see it, but grouping except "for visual purpouses" doesn't have functionality at all.
To avoid things I stumbled on, it's better concept to open new project and make new assembly set.

Regards,
K.
  Top
Walaa
Support Team



Location:

Joined on:
21-Aug-2005 16:03:48
Posted:
14429 posts
# Posted on: 30-Jan-2015 17:30:51.  
Group can be used to visually separate items, and/or to separate them in code/projects.
I'll raise your request for this feature.


  Top
Otis
LLBLGen Pro Team



Location:
The Hague, The Netherlands
Joined on:
17-Aug-2003 18:00:36
Posted:
37236 posts
# Posted on: 31-Jan-2015 11:43:13.  
Grouping in the designer is either for having a way to manage large(r) groups of entities together if they have to be in the same model or it's used to define different projects on the same target database(s).

You want to use 1 llblgen pro project with actually 2 models on 2 databases, so you group as different projects but also want to have everything separated, so why not just create two projects? The group name isn't present in the connection string as for both grouping types we have it doesn't add anything: the connection string is related to the target DB server, and it's the same for both projects.
Frans Bouma
LLBLGen Pro / ORM Profiler Lead Developer | Blog | Twitter
 
Top
Keiser
User



Location:

Joined on:
21-Apr-2010 11:09:32
Posted:
17 posts
# Posted on: 31-Jan-2015 14:53:54.  
Yes I figured that out at the end and using 2 different projects at the end.
In my particular case, I thought it would be easier to maintain 1 project, but as you both stated above because of limitations it's not possible.
With let say feature upgrade targeting group name usage in templates, I would be able to get that. Anyway as said above I went with 2 different projects approach.

Unfortunately I had experience with 2 same DB schema in the same project that led me to writing "overrides" of methods using AccessAdapter with 2 different constructors. I wasn't happy with that either as I had 2 same methods for entity/SP one targeting one ctor and the other 2nd one. It was too late to swap to 2 different projects as maintenance of such assembly is not quite nice as someone would expect. (at that time I was not engaged with that part of the project).
And also I would add, it's not separation needed per connection string but also per transaction manager, maybe somewhere else also.

Anyway visual separation has it's usage, but project separation, I don't see it as a good, clean way, especially because of missing group name variable missing in templates. (I wanted to have "one" assembly for both different schema, as using the same on the same side, mainly going to target db, and occasionally fetching data from history db). On the other hand I could load 2 projects generated per group name (with project separation setting), I haven't tried that, so cannot say nothing pro/cons for that. At the end to me it seems better to use 2 different projects.

Thanks for clarification!
K.

P.S. I don't know if it's bug but with project separation per group name, for some reason, i got few SP generated under 2nd group, where they didn't exist in DB at all. (might be the problem in template I used)


  Top
daelmo
Support Team



Location:
Guatemala City
Joined on:
28-Nov-2005 23:35:24
Posted:
8034 posts
# Posted on: 02-Feb-2015 08:07:45.  
The group name is appended to the namespace, the project filename, if the grouping is set to different projects. It's also available in the templates, but not used is connectionString. You can create your own version of the template that generate the connectionString name and logic, but the logic seems to emit a connection string per schema, nor per group. There is always a way though.

Anyway, I also think that your final approach (create separate LLBLGen projects) is more suitable in your scenario.
David Elizondo
LLBLGen'ing (articles and code snippets) | linkedin | twitter
 
Top
Otis
LLBLGen Pro Team



Location:
The Hague, The Netherlands
Joined on:
17-Aug-2003 18:00:36
Posted:
37236 posts
# Posted on: 02-Feb-2015 09:14:29.  
I also think there's some confusion. This morning I realized that 'As separate projects' could mean two things: as separate LLBLGen Pro projects and as separate VS.NET projects (which is the real intention of the setting value). I think you saw it as 'separate LLBLGen Pro projects', correct? Regular Smiley In case you did, that indeed will not match how it is implemented and look buggy. It's intended to be as separate output projects, so 1 llblgen pro project, separate output projects/code bases.

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



Location:

Joined on:
21-Apr-2010 11:09:32
Posted:
17 posts
# Posted on: 02-Feb-2015 11:55:03.  
Otis wrote:
I also think there's some confusion. This morning I realized that 'As separate projects' could mean two things: as separate LLBLGen Pro projects and as separate VS.NET projects (which is the real intention of the setting value). I think you saw it as 'separate LLBLGen Pro projects', correct? Regular Smiley In case you did, that indeed will not match how it is implemented and look buggy. It's intended to be as separate output projects, so 1 llblgen pro project, separate output projects/code bases.


yeap, you are right. I did found out that at the end Regular Smiley

As for custom templates, connection strings, yes I modified template to adjust output to my programming skills, just by adding additional things and minor modifications.
So talking about separate output, I find it useful to provide GroupName as custom variable in templates also. (Didn't get that in docs, might be that somehow I missed it)
  Top
Walaa
Support Team



Location:

Joined on:
21-Aug-2005 16:03:48
Posted:
14429 posts
# Posted on: 02-Feb-2015 23:23:52.  
And I think you also need it to be a parameter of the CodeEmitter task performer.
This is not currently available.


  Top
Otis
LLBLGen Pro Team



Location:
The Hague, The Netherlands
Joined on:
17-Aug-2003 18:00:36
Posted:
37236 posts
# Posted on: 03-Feb-2015 16:46:54.  
It is available, on the executingGenerator, in the property ActiveSourceElementsContainerNameRaw and its CLSCompliant variant ActiveSourceElementsContainerName

See the Designer's reference manual -> GeneratorCore assembly Regular Smiley
Frans Bouma
LLBLGen Pro / ORM Profiler Lead Developer | Blog | Twitter
 
Top
Pages: 1  


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

Version: 2.1.12172008 Final.