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 guys, Firstly, I have to say that Lightspeed is great. In two days and no c# experience I got a web service up and running talking to Oracle! While I was doing this though, I ran into a small bug. When dragging the table into VS2010 from my data source, the generated C# code is created and I can see all the various class members and their [Column("<NAME>")] directives. For some parameters, however, the directive is not generated. For example, I have one table which has a number of columns (25 or so) and one of these is a long which contains a link to another DB table. This parameter does not get automatically added a directive for the column, which means that queries fail due to a mismatched column name. The solution is to add the missing [Column("<NAME>"]) to the generated code, but this gets changed each time the data model is update. 1. has anyone else seen this? 2. Is there a fix? 3. Is there a way to make the workaround stick, if there is no fix currently? Thanks in advance!
|
|
|
I've seen this before and posted about it. Columns with FK constraints on them don't get added to the model unless the other table is also an entity in the model. Ivan mentioned that they might consider fixing it in the future, but for now you can do one of two things: keep doing it manually (but put it in a partial class in a separate file, not in the generated code--that way it won't get overwritten) or add the table that your long column references to the model as well. You don't have to use it, but its presence will allow you to reference the column in your entity.
-Kris- |
|
|
Thanks Kris. Just to clarify, this doesn't seem to be exactly the same as your situation as I have the foreign table in my data view. I can even use LINQ to make queries using the database's relationships, but the execution will fail unless I explicitly put the workaround in.
|
|
|
Further to this issue, it seems that also number fields are not being correctly interpreted when creating the generated .cs file. If I bring in a table with long ID numbers from my Oracle instance to the LightSpeed data model, they are created as long values, rather than Nullable long values. The database table definition specifies that null is acceptable on this column. Is this a known issue?
Thanks, |
|
|
Hi Emlyn, Glad to hear that LightSpeed has helped you get up and running so quickly! For the mismatched column name on the association foreign key, you can specify this by selecting the association arrow and specifying its Column Name in the Properties window. We should be setting this automatically if it isn't the default. (Note that we don't infer a Column Name if we were able to make the field name the same as the column name; this is because LightSpeed defaults to using the field name as the column name, so the override isn't necessary in that case.) If we're not doing this then could you share the relevant bit of the database schema so we can see try to get it fixed? Thanks! For the nullable ID issue, I'm not sure whether you're talking about the entity ID column (primary key) or a foreign key column. If you're talking about the entity ID (primary key), LightSpeed doesn't permit that to be nullable. Every entity in LightSpeed must have an ID. You might be able to work around this by mapping your nullable ID column to a composite key that happens to have only one field, but I think you'll still run into problems because LightSpeed won't be able to distinguish between entities with the same NULL ID. If you're talking about a foreign key, we do of course support nullable associations. Again, we should be inferring association nullability correctly and if we're not then we'd love to see your schema to try to reproduce it. |
|
|
Hi Ivan,
This same column is a case where the database schema permits null values as the column is a foreign key and this information is shown if I look at the design view of the data source in VS2010. The description of the column is: data type NUMBER Not Null UNCHECKED Precision 10 Scale 0
I can't send you a copy of the schema, but can help you with any further info to help fix these two problems. |
|
|
Thanks Emlyn. I think we may be mishandling the underscore -- we'll look into that and try to get you a fix, but for now manually adding the Column Name setting should sort it out. Regarding the nullable column, looking at the description you posted I see: [quote user="EmlynB"]Not Null UNCHECKED[/quote] That 'Not Null' implies to me than the column is not nullable in the database, which is why we are inferring it as not nullable. However, I'm not sure what the import of that UNCHECKED modifier is. Is this an Oracle annotation indicating that the Not Null constraint should be ignored? If so, is the Not Null constraint correct? Pardon my ignorance here, I'm not familiar with all the details of Oracle and my googles are weak today... |
|
|
Regarding the Not null - this is a UI checkbox on the Table Design page in VS2010 My understanding - if it is CHECKED then the DB does not allow Null values. If it is UNCHECKED then the DB allows Null values. I'm just showing you what the VS2010 design window gets and the settings that are shown. In this case, the UNCHECKED setting means that null values are allowed in the column. Thanks for the speedy response - I'll continue to use the workaround for now.
|
|
|
Hi Emlyn, Thanks for the clarification. Unfortunately, although I can now see the checkbox you're talking about, I haven't been able to reproduce either the underscore issue or the nullable numbers issue. In the former case LightSpeed appears to be automatically marking up the column name correctly, and in the latter case it is marking the property as nullable as specified in the database. I realise you can't share your table schema as written, but is it possible for you to create an anonymised version (and verify that it exhibits the same issues) and share that with us? You can email the CREATE TABLE script to support (at) mindscape.co.nz if you are uncomfortable posting it even when it is anonymised, and of course we will treat it as confidential. Alternatively, if you have already manually fixed up everything you need for now and you don't need us to investigate further at this time, let us know and we can close this off. Thanks! |
|
|
Ok, well i'm good for now with the manual patches and if it becomes more of a problem, I'll send you a schema.
|
|