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: I've been using the following query for the past couple of weeks and it works fine. // Determine if there are any collection entries that are People - Ensure 'freshness'! Executing the latter results in a LightSpeedException, "Query Error: Could not find field [TypeDiscriminator] on model [CollectionEntry]" Here are some model details ( I've had to change some of the names since my model is pretty sensitive ) A base Objects table which has derived tables of Collections and TypedEntities ( ObjDiscriminator in the Objects table is used to discriminated between a Collection and TypedEntity ) Any suggestions? |
|
|
Does CollectionEntry have a base class? What inheritance model(s) are you using? Would it be possible for you to put together a cut-down repro (with the names suitably sanitised) that you could send to us? |
|
|
Hi Ivan: The CollectionEntry table does not inherit from any table. I'm using the 'ClassTableInheritance' model. I can certainly do that, unfortunately I'm in Canada and just got home from the office so it will be in another eight hours before I can send a sanitized model. |
|
|
Hi Ivan: Managed to get back into the office tonight and made a small sanitized version of our model. It may seem really silly with the lack of fields but it should reproduce the problem. Let me know if you need anything else or have problems with the LightSpeed model.
The simpler query of: uow.CollectionEntries.Where( entry => entry.CollectionId = _collection && entry.Object is Collection ); Also generates a similar LightSpeed exception as in the original post. |
|
|
Okay, I've reproduced this -- it's an issue with our handling of the "is" operator. (This didn't occur in your previous query because that was using LINQ to Objects against an EntityCollection, so LightSpeed didn't get involved.) Unfortunately, I don't think we'll be able to get you a quick fix for this, because you're using multiple different discriminators (ObjDiscriminator and TypeDiscriminator), which means we can't just join to the Objects table and check the discriminator value. Multiple discriminators isn't a scenario we have ever tested and I'm not sure to what extent we can support it. (And yes, I acknowledge that the API is misleading here. In retrospect, we should have split the discriminator configuration into a one-off "discriminator column" at the root of the hierarchy and only allowed the "discriminator value" to be set at individual levels.) Is it an option for you to merge ObjDiscriminator and TypeDiscriminator into a single discriminator column in the Objects table? If so, I think I can probably get you a workaround and/or fix pretty quickly. Otherwise, you may have to fall back on re-querying the collection and then using LINQ to Objects as you did before. You can keep this down to one database query by using a named aggregate on Collection to eager-load the entries, so this should be very nearly as efficient as loading the entries by CollectionId. |
|
|
Our model is actually quite a bit larger than the sample I sent you and we were even planning on having a third level discriminator. I'll try and give an example of our data hierarchy without using our entity names We have a base Objects table with derived classes of Collection and Vehicle. From Vehicle we have other derived types of Ground and Air. From Ground and Air type we lastly have derived types of Car and Trunk for Ground and Blimp and Plane for Air. Again these really are our entity names but we have this hierarchy in order to share common information and most importantly relationships at key levels. For example a 'Vehicle' may have a relationship to one or more engines or manufacturing plants. I'll discuss the issue with our DBA tomorrow to see if we can compress some of the hierarchy and utilize another LightSpeed inheritance model, or would that not help either? Thanks for the promptly investigating this issue. |
|
|
The issue isn't the inheritance model per se -- it's the use of multiple discriminator columns. What I'm suggesting is that you compress the multiple discriminators into one single hierarchy-wide discriminator. For example, create an ObjectKind column in the ObjectsTable, and use that *throughout* your hierarchy. Thus: Collection: ObjectKind = 1 The class table inheritance model is happy to deal with multiple levels of inheritance, so all of these can still be separate tables, and the polymorphism will still work correctly. |
|
|
Ok I'll certainly give that a try. I thought I needed the single discriminator per level of my hierarchy, i.e. for a Air ( Obj = 2, Type =2 ). So in the designer when I'm creating the inheritance association between the 'Trucks' and 'Vehicles' table I can specify the discriminator as 'ObjectKind = 6' even though the column 'ObjectKind' isn't in the table 'Vehicles'? |
|
|
That's right. The discriminator column only needs to exist in the root table. |
|
|
Morning Ivan: I began by removing the second level discriminator ( TypeDiscriminator ) from the tables and model. Next I updated the inheritance associations for each table in the inheritance hierarchy to reflect a value of the discriminator ( ObjDiscriminator ) in the Objects root table. Running those changes the code continues to work even seems a bit faster. However, the original query error is still present: if( mySession.CollectionEntries.Any( entry => entry.CollectionId == _collection.Id && Results in a LightSpeed exception the message is now. "Query Error: Could not find field [ObjDiscriminator] on model [CollectionEntry]" The CollectionEntry table is as follows:
|
|
|
Yes, sorry, I wasn't clear. Collapsing down to a single discriminator doesn't fix the problem, but it opens the door to a workaround, which is to query on e.Object.ObjDiscriminator: mySession.CollectionEntries (where 7 is the Car discriminator value; obviously you'll want to replace this with a named constant if you take this approach). The downside of this (apart from readability) is that it only works for leaf classes: if Car has derived types of its own then the query needs to OR in those derived types: ...&& (e.Object.ObjDiscriminator == Sedan || e.Object.ObjDiscriminator == Truck)... So we will look into getting you a fix for the "is" operator but hopefully the numeric check will work for now. |
|
|
Hi Ivan: Thanks for the prompt response as always. This numeric work around will allow me to send out some application changes while I wait for the fix. Thanks again for addressing this issue and providing me with a workaround so quickly.
|
|
|
There'll be a fix for the "'is' operator on association" issue in the 17 Sept nightly, available from about 1500 GMT. At this stage I've only fixed it for a single level of association traversal (e.g. e.Object is Person): it won't work for multiple levels (e.g. something.Entry.Object is Person). But this should suffice for you I believe. As always, let us know if you run into any problems with it. |
|
|
Hi Ivan: Finally got to test the new build today and the update to the query seems to be working. Thanks again. |
|
|
Aha... That makes sense, I guess. Let me give it a try and get back to you. Thanks, Robert |
|