I have a project with a base namespace of:

Server.Framework

I have multiple catalogs I need to pull from in Oracle.

CoreCatalog CustomerOneCatalog CustomerTwoCatalog

Now, CustomerOneCatalog & CustomerTwoCatalog are identical schema wise, but, the data cannot be in one catalog.

I'm wondering how I can add a namespace based on catalog, so that my library would look like this.

Server.Framework.Core Server.Framework.CustomerOne Server.Framework.CustomerTwo

I could use seperate projects, BUT my customer schemas have references back to the core schema, so keeping them in the project together SHOULD allow LLBL to generate the relationships, or am I wrong?

I think you are speaking about branching the EntityClasses namespace only, right? eg. Server.Framework.EntityClasses.Core Server.Framework.EntityClasses.CustomerOne Server.Framework.EntityClasses.CustomerTwo

Walaa wrote:

I think you are speaking about branching the EntityClasses namespace only, right? eg. Server.Framework.EntityClasses.Core Server.Framework.EntityClasses.CustomerOne Server.Framework.EntityClasses.CustomerTwo

It would have to be for collections as well.

Basically I want 1 project that I could have 2 vehicle entities in... one touching customerOne, the other touching customerTwo.

And I want them in the same project so that I can keep my references from customerOne.Vehicle and customerTwo.Vehicle back to my core.VehicleColor entity.

Hope that makes sense.

If you have two entity types Vehicle, which are thus different abstract entities, why would you name them the same?

The grouping per namespace is a request that's been made a couple of times and we also tried to implement it a couple of times. The main thing that kept it from being a feature was that it turned out to lead to completely separate projects: A generated project has one EntityType enum, it has one set of factories etc.

To group entities in different namespaces, with potentially entities with the same name, it would mean that these groups would need their own entitytype and their own set of factories. So that meant in effect, per group of entities a separate project being generated.

What I find a little odd is that in core, you apparently have foreign keys to both customer catalogs? Are you planning to have more customer schemas? Are customeronecatalog and customertwocatalog in use in the application at the same time? (or are you installing the application at customer1 with customeronecatalog and also at customer2 with customertwocatalog?)

Otis wrote:

If you have two entity types Vehicle, which are thus different abstract entities, why would you name them the same?

The grouping per namespace is a request that's been made a couple of times and we also tried to implement it a couple of times. The main thing that kept it from being a feature was that it turned out to lead to completely separate projects: A generated project has one EntityType enum, it has one set of factories etc.

To group entities in different namespaces, with potentially entities with the same name, it would mean that these groups would need their own entitytype and their own set of factories. So that meant in effect, per group of entities a separate project being generated.

What I find a little odd is that in core, you apparently have foreign keys to both customer catalogs? Are you planning to have more customer schemas? Are customeronecatalog and customertwocatalog in use in the application at the same time? (or are you installing the application at customer1 with customeronecatalog and also at customer2 with customertwocatalog?)

The "Vehicle" entity is the same for both customers, but they touch different schemas in Oracle. Due the auto industry we have to seperate our clients data by schema.

The problem I have now is that I don't know how to in LLBL create my relations to another LLBL project.

We are building for infinite numbers of customers, all residing within the same oracle database, yet different schemas. All of our reference tables are specific to our company and therefore not replicated in each customer's schema.

I made three projects and thus three libraries. I just have no way to auto-hook my Server.Framework.CustomerOne.EntityClasses.Vehicle back to my Server.Framework.Core.EntityClasses.ExteriorColor automatically as if they would if all in one project.

Though, do you use 2 or more customer schemas in one application at runtime? If not, you can simply create the application for one customer schema, and use schema overwriting at runtime to connect to a different customer schema. So all references to customer1schema in the code will then be redirected by llblgen pro to customer2schema while all references to yoursharedappschema will stay referencing that schema.

Otis wrote:

Though, do you use 2 or more customer schemas in one application at runtime? If not, you can simply create the application for one customer schema, and use schema overwriting at runtime to connect to a different customer schema. So all references to customer1schema in the code will then be redirected by llblgen pro to customer2schema while all references to yoursharedappschema will stay referencing that schema.

We have one web based app that will touch more than one customer schema at a time, but I am planning the data retrieval through views, but there will be specific times where I will need to load a vehicle from a certain customer for editing.

I guess what I was originally looking for was a way in LLBL that I could edit an entity and give it a more defined namespace than the base namespace.

So if my base namespace is Server.Framework and I gave an entity the name of vehicle and a namespace of Server.Framework.CustomerOne, when I generated the project it would make the entity with the namespace specified, not the base.

Another thought I had... maybe I could inject the schema name, into the entity object name through a filter when I add a entity to a project.

Phuzakie wrote:

Otis wrote:

Though, do you use 2 or more customer schemas in one application at runtime? If not, you can simply create the application for one customer schema, and use schema overwriting at runtime to connect to a different customer schema. So all references to customer1schema in the code will then be redirected by llblgen pro to customer2schema while all references to yoursharedappschema will stay referencing that schema.

We have one web based app that will touch more than one customer schema at a time, but I am planning the data retrieval through views, but there will be specific times where I will need to load a vehicle from a certain customer for editing.

Then use adapter, and use adapter's abilities to set the schema name overwriting name to use per adapter instance. So you follow these steps: - create an instance of DataAccessAdapter by setting the name of the schema to use in the CTor of DataAccessAdapter - fetch your entity - dispose DataAccessAdapter.

SelfServicing isn't suitable for this, as described in the manual.

I guess what I was originally looking for was a way in LLBL that I could edit an entity and give it a more defined namespace than the base namespace.

So if my base namespace is Server.Framework and I gave an entity the name of vehicle and a namespace of Server.Framework.CustomerOne, when I generated the project it would make the entity with the namespace specified, not the base.

Another thought I had... maybe I could inject the schema name, into the entity object name through a filter when I add a entity to a project.

Having the two customer schemas in the same project would limit your flexibility if there would be a 3rd customer added to the project. With schema name overwriting per call (using adapter), you can create a project with just the core and the 1st customer schema and just add another schema for customer2 which you target using schema name overwriting through the ctor of DataAccessAdapter.

Just give it a try in a small testproject with 3 tables: one in core, one in schema for customer1 and one in the schema for customer2 and create a project with core and schema for customer1 in the project, generated code (adapter) and try to fetch/save entities in schema for customer1 (no name overwriting, or use the name for that schema anyway) and in schema for customer2 by using name overwriting through the CTor of DataAccessAdapter, just to get the idea how it works.