This thread looks to be a little on the old side and therefore may no longer be relevant. Please see if there is a newer thread on the subject and ensure you're using the most recent build of any software if your question regards a particular product.
This thread has been locked and is no longer accepting new posts, if you have a question regarding this topic please email us at support@mindscape.co.nz
|
Hi,
I need to add associations between entities but they are in separate models and different namespaces. When I try to add "Linked" entity to either of the model it expects both entities to be in the same model & namespace - so this fails.
What is the best work around this limitation? I can't change the namespace/model name because our current structure closely matches the various business units (departments, divisions, locations, etc.) so that's not an option. So far what I've done is:
I hope there's a better way of doing this. Do you plan on adding better support for such a scenario? I think in the real world it's very much likely that entities will not neatly share the same namespace and be conveniently placed in the same model - instead they'll be spread out all over the business layer. Ability to map and relate business objects closely the real world is critical, especially when tasked with mapping an entire enterprise into cohesive business layer.
Even with this work around there are limitations. First, I think the purpose of an ORM is undermined if one has to go into the DB anyway just to map foreign keys. Secondly, in my model if I choose "Update Database.." it doesn't recognize that the fields already exist because the db definition of those fields (which includes fk constraints) does not match the Lightspeed's definition of those fields so it tries to re-create them. And if I choose "Update From source.." it suggests to delete those fields from my model, for the same reason as before.
I hope you guys can come up with a better solution than my work around, I feel like LightSpeed and I are working against each other in trying to make this work. Thanks.
|
|
|
No, this is not currently possible using the designer. The designer currently generates everything into a single namespace. Multiple namespace support is on the wish list but it is not yet planned in. So your current workaround is the best we can offer right now. Sorry. |
|
|
Thanks for the reply Ivan. How complicated would it be to specify a different namespace? How soon do you plan on making this possible? Is there anyway it maybe be moved up on the wish list? I started of writing all the classes by hand and not using the designer (so I could get a better understanding of the inner workings) so this had never been a problem. But now that I've matured to using the designer and it's no longer possible this would mean having my code split into two partial classes for every .lsmodel file. When I go to demo this product to my co workers/management LightSpeed is going to look like a very unpolished product, especially since the designer over writes any hand written code so there's no other option to specify another partial class. If it's not possible to immediately have the full functionality implemented via the designer can you at least make it so that it doesn't over write my hand written code? also it would be nice if it can stop asking me to insert fields into the db that already exist on the db side but not in the desiger (when doing "Update Database.."). Thanks. |
|
|
It's true that you can't generate arbitrary code structures in the designer. The structures we support embrace the vast majority of cases, but there are always going to be cases like yours where people require specialised code generation to meet their particular policies or constraints, and we can't anticipate every possible case. For this reason, we make the code generation templates available for people to edit to fit their particular requirements, and the designer has an extensibility mechanism so that you can add additional settings (such as a per-entity namespace) for such edited templates to consume. In fact it would be possible (though very tedious) to implement your company's namespacing policy with the existing extensibility mechanisms. We're sorry if you feel this looks "unpolished" but the reality is that we have to bound the scope of what the designer can generate, or it wouldn't be a designer -- it would be a C# editor! *grin* [quote user="SR8"]Is there anyway it maybe be moved up on the wish list?[/quote] Sure. In fact we have moved it so far up the wish list that it will be available in tonight's build! (Available from about 1200 GMT.) What we've implemented is however not directly what you want but what a few other people have asked for which is per-entity namespaces. Well, sub-namespaces really -- all entities still live within the model namespace, but you can now specify an additional level of namespace through the entity Namespace property. Obviously you can assign the same namespace to all entities in a file if you wish, or you can assign namespaces in a more granular way within a single file. Note that all the files in a linked set must still have the same (base) namespace. But you can put the entities within those models into sub-namespaces. (NOTE: A link to an entity in a sub-namespace needs to go in the entity's sub-namespace.) Please give it a try and let us know if you run into any bugs! [quote user="SR8"]can you at least make it so that it doesn't over write my hand written code?[/quote] No, this is not an option. We have a friend who spent more than a year working on a code generator that preserved edits, and we can't afford to invest that much time on such a feature. So the generated code should be treated as 'for reference' -- it should never be hand edited. If you can't do what you need to do through a partial class, let us know and we'll see if we can provide an option, or as noted above you can edit the templates to address your custom requirement. [quote user="SR8"]also it would be nice if it can stop asking me to insert fields into the db that already exist on the db side but not in the desiger (when doing "Update Database..").[/quote] Hmm, if you have fields that already exist in the database then it shouldn't be offering to re-add them. Is this a primary key/foreign key overlap issue? We know the designer does not handle that situation well, but that should only be happening in existing databases where you shouldn't need to use LightSpeed to maintain them. If it's not the PK/FK overlap thing, we'd be keen to see a repro -- thanks! |
|
|
Can you please explain this statement a bit more: "(NOTE: A link to an entity in a sub-namespace needs to go in the entity's sub-namespace.)" Given that a have the "root" namespace "MyCompany.Model" and the sub namespaces "HumanResource" with an Entity "H1" and "Sales" with an Entity "S1". Are there any restriction for "H1" and "S1" regardings associations?
|
|
|
No. You can freely create associations across namespaces e.g. between HumanResources.H1 and Sales.S1. However, if H1 and S1 are in two separate files of a linked set (say FileH and FileS), then you will have a link-to-S1 in FileH, and a link-to-H1 in FileS (so that you can express the cross-file association). In this case, the link-to-S1 must be specified as being in the Sales namespace and the link-to-H1 must be specified as being in the HumanResources namespace. |
|
|
Ivan, is the sub-namespace concept like the database schema concept? |
|
|
Not really. Database schemas typically have some kind of security implication (e.g. user login is associated with a particular schema, schemas have owners, permissions can be assigned at schema level). An entity namespace is just a CLR namespace, a way of grouping names. |
|