OK, so I have a question,

Has anyone attempted to create a predicate builder?

I have started one but am no where near completion and just had a couple huge projects thrown at me and won't be able to finish it for awhile, but with our developers the largest stumbling block is the migaration from TSQL to Predicates.

Our people are all excellent TSQL coders but always run into, how do I make a predicate for X etc.

I am not really talking about a dynamic Predicate builder for runtime, just a utility to create static code to show the joins, and conditions.

My current project just uses 'placeholder' entity to table names, and requires some search and replace to actually use. I want to build this out to dynamically load LLBLGen entities (easy), use reflection to pull out the entities themselves (medium), associate the entities to tables (easy) then build a TSQL query on the tables and show the results in a grid (easy), then translate the query to say a block of C# code using predicates, use the GetQuery functionality of my SQL Logger function and display original vs new predicate version of sql, then cut/copy paste it into my app.

A different alternative I guess would be a predicate 'tester' where you dynamically load LLBLGen DLL, write a predicate and use the GetQuery functionality to show the user what they have built along the way, using a grid for result sets, but this approach is more for predicate validation than it is predicate building, but could be used in that manner in a trial/error approach.

OK, enough rambling, I was just curious if anyone else has done this etc. before I waste too much more time trying to complete this project, or if anyone had any input on what new users to LLBLGen would find useful.

John

jtgooding wrote:

Has anyone attempted to create a predicate builder? I have started one but am no where near completion and just had a couple huge projects thrown at me and won't be able to finish it for awhile, but with our developers the largest stumbling block is the migaration from TSQL to Predicates. Our people are all excellent TSQL coders but always run into, how do I make a predicate for X etc.

The eye-opener is most of the time that they have to shift focus from: "how do I create this SQL query I have in my head with predicates" to: "I want this, so I need to filter on this and that, how to write these filters?". Start with what you want, say a bunch of customer objects, and you want to filter them out from the large pile of objects in the db. So you have to formulate filters, which then takes a minute or so to browse the predicates in the documentation (which contain SQL equivalent snippets). It will then soon be common sense.

I'm considering a couple of helper tools to make filtering / querying easier. One is an OPath parser, another is a static code generator tool.

Hey, Frans. Have you had any thoughts as to when you'll expose SQL functions in code? I'm about to start another dev cycle and would like to be able to move away from stored procedures, etc this time around. If that's a ways off, I wouldn't mind building them myself if I had a bit of direction. Thanks.

Jeff...

jeffreygg wrote:

Hey, Frans. Have you had any thoughts as to when you'll expose SQL functions in code? I'm about to start another dev cycle and would like to be able to move away from stored procedures, etc this time around. If that's a ways off, I wouldn't mind building them myself if I had a bit of direction. Thanks.

Jeff...

No date set for that. I'm a bit undecided (how many times is that word used in the last couple of weeks ) about what to do with the next upgrade: just a designer upgrade or a designer + runtime upgrade. The latter is a bigger project but will take into account the functions.