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
|
LightSpeed DLL version: 3.1.1540.13882 I am using ClassTableInheritance with a discriminator of Type Int32. I am at the begining of this particular part of the model, so, right now, the model is very simple: Table Base has an FK of Table D - the relationship is marked with property Backreference Aggregates = GetZZZAggregate Table Dervided1 inherits from Table Base on a discriminator value of: 1 Table Dervided1 has FK of Table C - the relationship is marked also with property Backreference Aggregates = GetZZZAggregate Table Derived2 inherits from table Base on a discriminator value of: 6 The problem is that when I query with: query.AggregateName = "GetZZZAggregate"; I get but no SQL is generated to get Table C, the aggregate from the derived table. ie SQL submitted is of the form: SELECT ... LEFT OUTER JOIN LEFT OUTER JOIN WHERE ... SELECT ... Do you have any suggestions other than "You have spelt the aggregate name wrong somewhere" ?
|
|
|
Are you querying through the base class? We currently have an issue (on both single and class table inheritance) that named aggregates are considered only on associations declared at or above the level of the query class. For example, if you do a Find<Player>, then only associations on Player are considered, but if you do a Find<Cricketer>, then associations on both Cricketer and Player are considered. |
|
|
Ivan, Thanks for your response. I am querying through the base class. This is because at the point of the query I dont know whether what comes back is going to be of a particular derived class, ie it could be any of them and sometimes even it could be a collection consisting of some of each. Are you planning on fixing this issue, if so do you have a time frame ? Do you have any (preferred) work-arounds at this point ? |
|
|
I've asked Jeremy to take a look at this, and until I hear back from him I don't want to comment on the likelihood or timescales for a fix. He is overseas at the moment and has slightly irregular connectivity so please be aware he may not be able to respond until early next week. The only workaround I can think of at the moment is to move the FK to the base class table (and the association to the base class), make the FK nullable and have it null for rows that don't correspond to Derived1 entities. Whether this is worth doing depends on your timescale. If you need to optimise performance immediately because you are about to go live, then compromising your design this way may be an acceptable trade-off for the performance improvement. If you don't need to tune just yet, then it may be better to take the performance hit of lazy-loading for now while you're still in development, and revisit the issue when you know whether we are going to have a fix within your required time frame. |
|
|
There's a candidate fix for this in the latest nightly build. Let us know if you still see the problem. |
|