The PK fetches like
foo = new FooEntity( 1 ); // => Ok
foo = new FooEntity( 2 ); // => Error (not found)
can't be altered, as the filter produced for the entity is based on the PK field. Adding another filter is not what the framework should do, as it doesn't make sense for the framework.
There is a way to automate this, although I'm not sure if it will work in every part of the framework.
- create an include template for the dao classes. In there override CreatePrimaryKeyFilter. There, add the CustomerID filter to that filter. Also override the CreatePrimaryKeyFilters variant, if you use hierarchies. If you override the latter, you don't need to override the first.
- for the getmulti actions, it's a different story, you'll have to use a central method for that I think, which produces the real filter to use. The issue is that there's no virtual method to override in the GetMulti-call chain so you can't append your extra filter to the filter to use. The lazy loading methods for collections will use the generated CreateFilterUsingForeignKeys.
So it's complicated. The problem is also with prefetch paths, which have to get the filter.
If anything fails, a small change to the DQE of sqlserver is an option. As there's just 1 select query construction method, you can simply add the filter there, based on a property set for example. The only thing to overcome then is to avoid having the filter also added to subqueries (however it might be that that IS wanted).
If you don't want to alter the sourcecode, you can derive a class from the DynamicQueryEngine and override the selectquery construction method. The DAO classes set the DQE to use in the constructor. You could create a derived class for the DAO classes, set the DQE in THAT one's constructor (using a template of course) and then you can let the code instantiate instances of the new DAO classes in the collection classes and entity classes by overriding CreateDAOInstance() in which you create your own DAO variant.