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, Does LightSpeed currently support abstract base classes. I am currently testing with NWIND sample schema and I have defined a base class that simply contains DeletedOn and LockVersion fields and props. However, now I get the following error whenever trying to query or save: Query Error: Could not find field [Id] on model [Customer] The abstract base class is defined like so: public abstract class ks_Entity : Entity<Guid>{ private int? _LockVersion;[ Browsable(false)]public int? LockVersion{ get { return _LockVersion; }set { _LockVersion = value; }} private DateTime? _DeletedOn;[Browsable(false)]public DateTime? DeletedOn{ get { return _DeletedOn; }set { _DeletedOn = value; }} } Of course, Customer, Order, etc. now all derive from ks_Entity. I hope I'm just missing something obvious. Thanks, Kavan |
|
|
Hi Kavan, Yes. We use this style extensively in our own LightSpeed projects. Here's an example of one of ours: public abstract class EntityBase : Entity<int> Cheers, Andrew.
|
|
|
Hi Andrew, Is the EntityBase name a requirement? I made that one change and the earlier error went away. Thanks, Kavan |
|
|
Hi Kavan, No the name doesn't matter. I'll double-check whether there is an issue with the underscore. Cheers, Andrew. |
|
|
Hi Kavan, I had a look into this on behalf of Andrew and found that the naming of the class did not affect anything with LightSpeed. I experiemented both with a general name that included an underscore and naming the class exactly the same as you have named yours and neither time did this cause a failure. I trialed this on a large system that we have built that uses LightSpeed and all the tests passed happily. I'm not sure why only renaming the class would have resolved the issue for you but if things are now working I'll consider this case closed. If you have any more issues with the naming of your abstract class then please let me know. Hope that helps, John-Daniel |
|
|
Hi John, I actually have been able to recreate the bug. You are correct, it had nothing to do with the name of the base class. However, the bug is very real and I am emailing your support box with a project that duplicates the problem. In a nutshell, It seems the TypeModel is not correctly being setup correctly in all circumstances. The ID field and all fields declared in the abstract base were not being included in the derived class. It actually has to do with the order in which queries are called. For example, if I call a query on 'Customer' first, then no error, but if I call 'Order Details' first then 'Customer', problem. I had a great difficulty recreating the bug when setting up the bug repro project, but then I thought if I first query for 'EntityBase' knowing it will fail it might set the bug up. And that did the trick. All other ways were too hard to pin down. Check out the bug repro and let me know what you. Just make sure to check out the SQL for the customer query which is missing the ID field and causing the exception. Thanks again, Kavan |
|
|
Hi Kavan, Thanks for putting the repro together. We'll sort this out ASAP. Cheers, Andrew. |
|
|
Hi Kavan, I've been having a look into this issue however while I can recreate an issue with the repro, I don't believe it's valid recreation of the issue you are seeing. The case being that passing in EntityBase will always put LightSpeed into an invalid state because it expects this to be the name of a table (or derived entity type) and therefore sets up the internal type model to include EntityBase as a first class entity. Of course, once in an invalid state internally it makes the ability to test challenging as it's not an actual use case when the internal type model is in this state. I've spent about 6 hours just reviewing things internally looking for anything that stuck out and so far haven't found anything. I've tried running a Find() on most of the domain entities initially to see if I could get a load issue but have thus far failed to cause any problems unless I do load the EntityBase class. Is there any class in particular that should cause this? I tried the OrderDetails as you mentioned but that worked fine. Can you double check to ensure you're not accidentally requesting LightSpeed do a Find on a type that is not either a first class entity or a derived entity? Hopefully we can find the cause of this issue shortly. Cheers, John-Daniel |
|
|
Hi John-Daniel, The framework I am using automatically builds a catalog of types for UI generation and such. This process will pick-up all classes dervived from Entity. So if EntityBase is in between it also gets picked up. I can not ignore EntityBase since it contains properties that may need UI elements. This is what may latter cause a trigger for the error in the TypeModel. I still haven't tested, more from fear, an abstract chain with more than one abstract base. As LightSpeed is the framework, it really show check and guard against this type of error. Nonetheless, you guys have great product. I have had the unpleasure of working with many other ORMs (IdeaBlade, XPO, Genome, OpenAccess, just to name a few.) and they all have severe performance, maintability or modeling issues. What you provide is lightweight persistence that is highly tunable (i.e. Named Aggregates) and I'm sure you'll make it better with code generation and AOP (i.e. PostSharp). Thanks for all the hard work, Kavan |
|
|
Hi Kavan, I've added a check that causes an exception to be thrown if LightSpeed detects an invalid type request. Additionally, there should be no problem with multiple levels of abstract base classes - one of our internal projects has 3 levels in it's model. Cheers, Andrew. |
|
|
Hi Andrew, Thanks a lot. LightSpeed is truely awesome. Thanks, Kavan |
|