Frans, Its probably posted in another thread but if you would be so kind, when are you going to be integrating functions and features like case, substring, ... support into LLBLGen?

I grew impatient the other day and began implementing them myself

I'm about half way through I am guessing and stopped because of that same old nasty fear, the next release would have it, or even wouldn't have it and I would need to remerge my code.

I have a Custom_DataAccessAdapterTemplate file if people want it that allows you to call functions similar to stored procedures, the one I use has my debugging code that's in the 3'rd party section as well, but if people want it I can post it.

Unfortunatly this wasn't what I really wanted, I wanted the ability to create a TypedList, with one or more of the fields to be functions, well I did this, then I said hmm be nice to do case statements, substrings, etc. as well, so I'm working on a new custom field type that allows for custom aggregates type functions.

Obviously none of this has designer support which would be really cool, but in all honesty doesn't gain me a lot, since I frequently have self joining typed lists so I build them in code already.

My biggest problems is my implementation of this requires modification of the support classes, something I really don't like to do due to maintaining the changes with Frans's changes.

Secondly I kind of built a hidden entity to 'bind' the functions return values to, again to limit the places where I modify the original code, due to LLBLGen wanting persistence information from an Entity when building lists

Also I have no support for functions etc in the where clause, I haven't begun to look at that portion, currently I am only working with result field lists.

Doesn't help that management isn't in the office this week, and I'm bored for the 2 days I'm in the office, and sitting here debating on if I should or if I shouldn't

Sigh John

There will be two types of function support: 'system' functions and 'user functions'. System functions are things like case, substring, isnull and other stuff, user functions are functions the user wrote themselves and are callable in the db, for example a function which returns a value based on input and that value should be put as the value of a field.

Designer support for either category is hard as it easily ends up in a large editor which takes ages to get something defined, as the biggest problem is the parameters. I've planned to add function support in the (beta) release planned for april 2005. It's though a bit cumbersome to integrate parameterized function calls easily, so I've to think about a solution for this.

Functions in filters can be added today, using an IPredicate implementation (or a class deriving from Predicate).

I've cheated in quite a few places of my implementation, I created a hidden entity with one of each DB field type in it, mainly due to a few of your existing methods that want an actual entity to lookup persistence info.

Beyond that I modified the IEntityField object to hold a flag to mark the field as a 'custom field' i.e. function, and an additional couple of pieces that hold the extra information I need, and then defined a new create field overload for 'functions'.

It appears to be working overall, I still want to do a bit of cleanup, but as I said I just hate modifying the core libraries, vs. adding extensions through Custom_XXX templates.

So my end user code ends up looking like your standard custom TypedList code, just using an extra overload for the line that uses a function.

Actually my code is almost a raw sql injector to define a result field, I was going to make a much more full featured solution, but again I went with a solution that minimized the core changes, where my original solution had a new 'customfield' type and placed a lot more restrictions on the actual SQL that could be used

Think I will finish this piece up, and resign myself to throwing it out in April/May after testing of the new code is done, the number of times where we do Case statments to change nulls to 0 or emptystring, or use a user defined function to determine a calculation is rather high and it will be of some use till April, and allow me to avoid stored procs to keep our logic centralized whenever possible.

Thanks for the timeline and feature set, looking forward to it

John

The NULL -> 0 / "" feature is already build into the typed lists/views though, if you read a property, say myTypedList[0].CustomerID and it's NULL, you'll get 0 (the typedefaultvalue) if the field represents an integer. The actual value is still NULL though, which might cause some issues with databinding, as the dataset/table code for databinding is pretty obscure to say the least (read: nonstandard)