Couple of interesting features

Hello, We build CRM software and this kind of applications require vast customizations for each single customer.

We currently provide the end users with ability to add any number of custom fields and entities to the base ones.

However we just support SQL Server by now. Since we are planning to re-architect the whole application providing also Oracle support, I thought about employing your LightSpeed.

Your ORM is superb! However... :-) I stopped when I saw 2 big limitations (for our specific requirements).

1) Ability to add run-time, metadata driven schema additions (new fields/entities/relationships).

Basically we need to provide our customers the abilty to add custom fields (with no limitations in number/size) and also custom entities as needed. The idea is to "extend" the base schema the application provides 100% at runtime.

2) Ability to apply default-filtering rules to the data being queried.

In a CRM system, data is never accessed directly from tables or views, but it's always filtered according to the user hierarchy/permissions and other stuff that go REALLY beyond any view/function/etc...

My question is: Is it possible to apply "context-specific" queries to the actual request, so that, for instance, when I request the list of customers, the system applies a custom query/code appending the correct filtering to the underlying data?

The worst here is that the "permissions" can vary user by user, and entity by entity, so this is something I expect to do programmatically somehow injecting some "code".

Do you have any guide or idea about how to solve all this stuff? Thank you and keep up the great job!!

1. The mapping between CLR fields and database columns is baked very deeply into LightSpeed, so there's no way to add things to the schema without getting into runtime code generation. I posted some sample code for this at http://www.mindscapehq.com/blog/index.php/2011/04/19/defining-lightspeed-entities-at-run-time-part-1/ (3-part series).

In many cases however there is an easier approach -- put all the custom data into a single column as a XML document. This won't work if you need things like integrity checking, querying on custom fields, etc. but for simple cases it avoids the complexity of the dynamic entities solution.

1. See http://www.mindscapehq.com/forums/thread/261704 for discussion of ways of doing this and for a feature in current nightly builds that allows it to be done in a reusable, composable and declarative way. We remain open to suggestions for further improvements and additional requirements, though we'd suggest you place it in that thread so that other customers using this feature can chime in if it would affect them.