can LINQPad throw (or add a warning) when trying to modify a table with no PK?
A co-worker was trying to use LINQPad to update some rows in a table he had created in SSMS via 'select into' - the code he wrote was fine, it fetched the rows, modified them, and did SubmitChanges, but checking SQL Profiler, no updates were getting sent to SQL Server.
Thankfully we figured out it was the lack of primary key fairly quickly, but given the user experience here gives no indication of what's going on, it seems like it would be much more user-friendly to have some kind of UX (runtime exception, warning surfaced in the UI, something) to let the user know that what they're expecting to happen won't be happening.
* Having the instances of those table types contain getter-only properties is probably a bad idea (still not discoverable).
* Having the setters do a throw might make sense, but there's a possible (albeit unlikely) use case for modifying the values fetched and not intending to submit them back. IMHO, that's unlikely enough to warrant the change to throw in the setter (and could always add some kind of option to disable to the 'throw on set' as a runtime config var, although that's kind of ugly, admittedly)
* I'm assuming that doing a throw at SubmitChanges time likely isn't a simple option, since I'm guessing any such entities weren't getting tracked, so I'm not sure there's sufficient information available at SubmitChanges time to know whether changes were made to no-PK entities.
Thankfully we figured out it was the lack of primary key fairly quickly, but given the user experience here gives no indication of what's going on, it seems like it would be much more user-friendly to have some kind of UX (runtime exception, warning surfaced in the UI, something) to let the user know that what they're expecting to happen won't be happening.
* Having the instances of those table types contain getter-only properties is probably a bad idea (still not discoverable).
* Having the setters do a throw might make sense, but there's a possible (albeit unlikely) use case for modifying the values fetched and not intending to submit them back. IMHO, that's unlikely enough to warrant the change to throw in the setter (and could always add some kind of option to disable to the 'throw on set' as a runtime config var, although that's kind of ugly, admittedly)
* I'm assuming that doing a throw at SubmitChanges time likely isn't a simple option, since I'm guessing any such entities weren't getting tracked, so I'm not sure there's sufficient information available at SubmitChanges time to know whether changes were made to no-PK entities.
Comments
I'll add a no-pkey warning into the set accessors with the next build.