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, some strange things going on here. First, I am using Lightspeed 5.5 nightly build from 8 Dec 2015. Yeah I know it's a bit out of date but you all haven't been doing much with Lightspeed for quite a while now and I stopped checking. VS 2015 Update 3 with Oracle.DataAccess 4.121.2.0, Oracle database 11g version 11.2.0.3.0. IT upgraded the application running on the Oracle database (IQMS) over the weekend, and when they did so a lot of fields got changed. See the attached .docx file for a list of what changed. We had tested everything except writing to the database, as that is a seldom-used function of what we do with the database -- whoops! When IQMS changed the ITEM_NO field size from 25 to 50 Lightspeed complained when we tried to read the field and then write it back, and rightfully so. The reason I am writing you is that when I update the model from the database to get these new field size values, I get duplicate fields in several entities. I sent you the model project from the solution, so you should be able to see what I am talking about. When I manually delete the duplicates and re-run the Custom Tool from the menu, of course the duplicates are re-added to the model. Can you please have a quick look to see what might be happening? If I have time, I will get the latest nightly build and see if that has any effect. If I do, I will update this ticket as to what happened. Thanks, Dave |
|
|
|
|
Update - newest nightly build didn't help at all. This is a major pain, as there are no obvious ID fields and Lightspeed does a really bad job at guessing what they are supposed to be. Every time I find another and go in to fix it, I have to remove all the duplicate fields again. My only option is to load up an old version and inspect every entity to see how they are mapped, remap all the ID fields and then delete the duplicate fields. Once that is done, I can restart and test to see if I missed anything. If I did miss something, start over from the top. Apparently Lightspeed doesn't do very well updating from the source database in this case. So do we need to start looking for another ORM provider or will you at least try to keep up with the latest database versions? At one point the version of Oracle I am using wasn't supported, is that still the case? Will it ever be fully supported or are you really going to abandon the Lightspeed product? I really don't want to make the effort to switch to an inferior product (EF) but if you won't keep LS current I have no choice... :( |
|
|
|
|
Sorry to say we are not intending to make any updates to the Oracle provider. It does sound like something has changed in the newer release of Oracle that changes what we are getting back from the schema inspection queries that we run but for now we cannot support those newer versions. We do have a partner who does a lot of work with LightSpeed over Oracle who has probably already addressed this issue that I will check in with to see if they have a patch that we could merge back in.
|
|
|
|
|
"Sorry to say we are not intending to make any updates to the Oracle provider." Ouch. That effectively puts a nail in the Lightspeed coffin. Is there any way to get rid of the offending duplicate fields so they don't come back every time I make a small change? We can't just rip this out and replace it overnight so I need to maintain the app using Lightspeed for the time being. Any help at all would be most appreciated. Thanks for the ride, Dave |
|
|
|
|
After a bit of digging around into exactly what changed and what was causing the errors I discovered this isn't an Oracle version issue at all. I found I can simply not take many of the suggested changes and then reassign the ID field on a couple of the "mapping" views that don't actually have ID fields. This is a hole in your approach to mapping, IMO. I believe you call them "through associations" but entities (views) that exist solely for the purpose of associating 2 tables often don't have or need ID fields. I am attaching a Snip of the suggested Updates to the Model, similar to what I attached before but with more of the suggested changes unchecked. I will then need to assign the correct Identity field to the 2 views that your mapper didn't know what to do with and everything works again. This is a bit of a pain, but I'm not sure EF or any other ORM out there would do any better. I am a bit disappointed in your response, though. You seemed to take the "oh it must not deal well with the new version of Oracle" approach instead of taking a little time to see what was really going on. I still get the feeling Lightspeed is something you have to keep supporting because people still use it, but you'd really rather not... Sad. Still a great product, but the support is dwindling fast. Thanks, Dave |
|
|
|
|
All entities (including many to many through association based ones) must have an Id property (either a column or a composite) which can uniquely identify the entity. This has always been one of the conventions with LightSpeed so its not a hole as such but its a deliberate decision we made early on with the product - it definitely impacts scenarios where the is no natural Id available but we don't intend to handle mapping every scenario possible. In terms of the investigation side, yep understand your pain, and certainly we can no longer spend as much time as we used to digging into things without immediate repros etc. From our side of the fence the product has been very stable for a long period of time and being used in production by a large number of customers so our focus is on continuing to cover bug fixes around the existing product functionality and database targets. Unfortunately the economics and the state of the market simply don't stack up to allow us to spend additional time revving on newer things.
|
|
|
|
|
Jeremy - Thanks for the explanation, I understand your position -- on most things. I don't understand the concept of not supporting the latest (or even 1 behind the latest) version of the databases you do claim to support, though. That seems like planned obsolescence to me and doesn't inspire confidence the product will be viable long-term. I still love the way Lightspeed works for me, and will continue to use it as long as it is viable. The fact you don't plan to support database versions beyond what you originally designed it for is a huge red flag, though. I see an impending end-of-life notice waiting on the sidelines... Cheers! Dave |
|
|
|
