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
|
Hello, I find myself creating several "research" projects a day reproduce LightSpeed issues I find in larger projects. The process is error prone. If any settings differ between migrations, model and code, then it requires more time to diagnose the issue. As a result, I'm not submitting some issues due to time constraints. Would it be possible when code is generated for a LightSpeed model that it generates a subclass of LightSpeedContext which is already configured with the connection string, provider and pluralization properties defined in the model? It would also be beneficial if the connection string and provider of the model is updated when migrations are executed via the migrations menu. This way we know the settings are identical between migrations, model and code (since a subclass of LightSpeedContext is created). Having a LightSpeed project templates for a class library, console application etc may speed up the process too. To further improve the time it takes to start with the project, I'd like to suggest that the model contains additional properties such as CommandTimeout, CascadeDeletes, DetectPropertyNames etc and that those properties be set in the subclass of the CloudContext being created. But this is perhaps asking too much. :) Thanks, Werner |
|
|
|
|
Thanks for the suggestion, I agree this would be useful. Because this is going to be mostly of use in "getting started quickly" situations I am going to look at including this in the Getting Started dialog for quickly copy/pasting out. I will also investigate how we might include this in the code gen. Will let you know once I have made some updates here. I will have a look into the migrations and have a think about syncronizing those connection strings. I would rather not have it forcibly override if something is already there but some kind of prompt to update would probably be appropriate. Alternatively a setting to force syncronization may also work although discoverability of such a setting may be a problem :) Will let you know once I have had a chance to look into this also.
|
|
|
|
