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
|
How do I map the different LS models' entities and properties to different tables and different columns? |
|
|
Hmm... just did another search and a quick skim through. I'm not sure but I guess it's in this series of articles? I'll be reading it later but I have a couple of initial questions: Is it available to try out in LS3? Any further information do I need to know about when I read up on it? Thanks. |
|
|
Hmm... I've just discovered this. Just need to confirm. Is filling the fields in the model designer the fastest way? :O |
|
|
Yes, normally you would fill in the Table Name and Column Name fields in the model designer. (If you are hand-coding entities, you would use TableAttribute and ColumnAttribute.) You can avoid this if your tables and columns are named in a consistent way. Then you can use LightSpeedContext.NamingStrategy to encapsulate the mapping. I guess if you wanted to enter mappings in a XML or text file then you could also implement a naming strategy to read from such a file. However note that both of these approaches sacrifice designer sync because the naming strategy is a run-time thing, not a design-time thing. Or is your problem that you want to map the names differently depending on which database you are connecting to? That isn't built in, but again you could do it using LightSpeedContext.NamingStrategy -- have different naming strategies for the two databases, or have a naming strategy that you can parameterise through a mapping file. The article you mention upthread refers to defining entities at run time and would not normally be required for table and column mapping. However, if you do need mapping to different names depending on the database, then yes, you could also use that approach. Howwever, the problem then is that you have to do everything using dynamic or the metadata API -- you won't have a strong-typed programming model, and therefore won't be able to use LINQ. If you do feel this is a good fit for your application, yes, it works in LightSpeed 3, except for the metadata stuff which is LS4-only. |
|
|
Let's say I already have a model with a user login table done built in the designer. I also have a legacy database with a populated user login table. I decided to copy that table and bring it into the database. What are the best ways to remap the username/id and password columns only to the user and password columns of the newly brought in table? (In my case, the newer table has user, password columns while the older table has user, password, email, phone, add, etc columns... Also, what if in case the first table has and additional email column instead and I want to map that column to a column on another table which links(FK) to the legacy user login table that was brought in?)
PS. BTW, not sure if this has been reported/fixed. I had problems when I unknowingly named my table 'User' with my first foray into the LS designer. Finally figured out you guys didn't do the '[User]' thing. So I'm reporting it here additionally. |
|
|
Not quite sure what you're describing here. Are you wanting to have a single entity type that maps to two different database tables with different schemas? That isn't readily possible. You certainly can't map a single entity type to two tables in the same database (where would we save it to?); you could possibly do it across two different databases by using an INamingStrategy to set up different mappings in different LightSpeedContexts, though handling the additional columns would be very tricky. Or are you just wanting to change the mappings on the UserLogin entity so that it maps to your legacy table instead of the designer-generated table? In that case you can do it using the Table Name and Column Name settings, and adding properties to the entity as required (Update From Source should handle this once the table mapping is set up). |
|
|
Yes. That's what I meant. I guess it could be saved by just copying the additional tables into the model designer. I was just asking.
But I'm fine with doing what you said in the second paragraph. So you've answered my question. Thanks. |
|