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
|
What is the Custom Resolver property on 1-to-many assocations and is there a good example on how to use it? I'd like to be able to model a 1-to-many association in the designer, but provide my own filtering of the association.
I'm using single table inheritance, but want two things. I have one table that will contain associations to multiple inherited types. For example: A Product contains associations to many PriceA and PriceB records. Both PriceA and PriceB use single table inheritance from Price. The problem is I don't want two Id fields in the generated Price table. I would like to be able to have just one, because a Price is either PriceA or PriceB, but not both so one of the fields will always be null. If I change my associations from PriceA and PriceB to the underlying Price entity then I only get only one PriceId column and not the two. The problem with this is that I would still like to be able to reference Product.PriceA and Product.PriceB which is not possible. I know I can create a partial class and roll my own properties for this, but I was hoping there would be something built-in that I could leverage. Thanks! |
|
|
The custom resolver is used to look up associated entities in ways other than "FK field to ID" -- it basically allows you to specify a custom query expression for performing the lookup. It was developed for the scenario of "cross-cutting keys," where part of the FK is part of the PK (but there are other parts of the FK which are not part of the PK). See http://www.mindscape.co.nz/forums/Thread.aspx?ThreadID=2653 for more info. The intent is that it should be more broadly usable for e.g. associating on a unique column instead of the ID, but we have not tested these broader uses and we are aware of some limitations in the feature which is why we haven't announced it more widely. You might be able to use custom resolvers for your scenario, by declaring two associations which resolve using the same PriceId field, but I think a better bet is to have a single Price association, but make it private and surface wrapper APIs in the partial class, e.g. public PriceA PriceA { |
|