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, We're currently working on a .net project forecasted to run against a SQL database server. The project development is in its final phase and now we've to face a change in the database server requirements since it'll now run on an Oracle server. My question is : Could Lightspeed help us in migrating the existing code (using Linq-to-SQL) to Linq-to-Oracle without having us to go back to ADO.net ? Thanks for your help. |
|
|
It depends on the kind of queries that you're making. LightSpeed doesn't support the full feature set of LINQ to SQL (in particular, there is no support for join or group by, and there are limitations around some of the scalar operators such as Any and All). So if your application depends heavily on complex LINQ queries then LightSpeed may not be a good bet (though in some cases you may still be able to work around these with views). Otherwise, there is a good chance LightSpeed could help. You would need to migrate your existing .dbml file to a .lsmodel file, though given that the database already exists you could probably do that by just re-dragging the tables. The XxxUnitOfWork class is a good fit for the LINQ to SQL XxxDataContext class, though you would need to modify the creation code to use a LightSpeedContext<XxxUnitOfWork> rather than just new-ing up the XxxDataContext directly. But these should be relatively minor changes. You would of course need to test for subtle behavioural differences such as eager vs. lazy loading, but it would probably be possible to address these by tweaking of the LightSpeed model. If it's possible for you to isolate a small (8 or fewer tables) part of your model, e.g. admin functionality, then it may be worth doing a quick spike with the free LightSpeed Express Edition to see what sort of integration issues you have and to get a feel for whether the rest of the code will readily port. |
|
|
I noticed that group by doesn't work with LINQ to SQL in my application and found this thread. Any idea if you plan on implementing the missing bits of LINQ to SQL integration mentioned above (specifically join and group by support)? If so, any rough guess on when that might happen (weeks, months)? Thanks. Dan |
|
|
We would like to implement join support at some point. We don't have any work planned on this at present, but it is one of the possible features on the table for a future v3 release. (I should emphasise that we have not even begun to prioritise features for v3 yet so I cannot tell you whether join support is likely to make the cut or not.) Group by is less likely to happen because so far we have fewer people asking for it, but we are keeping it in mind. In the meantime, depending on your requirements, your join requirements might be met by a view, or by the support for stored procedures which was added post-2.1 RTM (see http://www.mindscape.co.nz/blog/index.php/2008/10/20/stored-procedures-and-lightspeed/) -- though obviously these involve predefining the join in the database rather than being able to create ad hoc joins in code. |
|