-
Correct, properties and methods you add in the partial class are preserved and do extend the model. If you add a persistent field in a partial class, then you may use it as a "normal" property in queries. Transient fields, and properties without a backing field (such as computed properties), may NOT be used in queries because they do not map to the database. Fields added in partial classes are not displayed in the designer because the flow from the design surface to the code is one-way
-
Hmm, I think the NoReverseAssociation attribute will take precedence which makes this merely *ahem* 'undesirable.' Regardless, it will be fixed in the 11 Sept nightly.
-
Correct. Using the designer to create persistent properties is the best way to ensure correctness of the LightSpeed model and consistency with the database. Partial classes are generally best reserved for things which LightSpeed doesn't care about (but you do): * Computed properties (by which I mean "computed in code" rather than computed columns in the database) * Transient fields (and their associated properties) * Domain methods * Customising setter logic The first three are "non
-
Could you just clarify for me: you originally said you were using VS2010 English on Win7 Spanish (and this was the configuration I tested), but it now sounds like you are using VS2010 Spanish on Win7 Spanish. Is that correct? We had an issue (now fixed) with non-English versions of VS2008; it's possible it's come back in VS2010. If you can confirm that the issue is with Spanish VS2010 then I can take another look into it. As a workaround, you could try copying the zip file (not folder) to
-
The answer is always "It depends." If you want to be able to query on the age (e.g. "where p.Age > 18"), then it has to be represented in the database, because we're going to translate that Age reference to SQL. (There are ways around this with a bit of LINQ expression ninja magic, but they're a bit crude.) So in this case you would use a computed column in the database and a read-only field in LightSpeed. If, however, you only want to use the age client-side, for example
-
Could you provide us with a small model that exhibits the issue so we can try to reproduce this here please? Thanks!
-
Unfortunately we have no experience with XtraReports so I'm afraid we can't really advise on this. However, most reporting tools have *some* way of running against an object model, so I don't *think* you should need to fall back to data sets -- but I don't know what the required incantations would be. Not sure if we have any other XtraReports users who could help you...?
-
I've logged a feature request for this, but there are some difficulties with it, so it probably won't happen in the near future. (One of the problems is that, with this change, if we see a nullable FK in the database, we won't know whether the nullability of the FK is meant to represent 'not dependent' or 'dependent, but not used in all derived types,' so won't be able to warn if the association in the model has incorrect nullability.) Sorry.
-
Thanks for catching this. It too will be fixed in the 11 Sept nightly.
-
Unfortunately we do not currently support negated expressions in Any or All clauses. I have looked into whether this would be easy to address but I'm afraid it doesn't look like we'll be able to provide a quick fix for this. Jeremy has suggested that you may be able to achieve what you need with a join, but warns that this could return duplicate instances.