Is it possible to collect object usage information during compilation?

[DaveG via Digitalmars-d]

On Saturday, 10 January 2015 at 13:19:19 UTC, Martin Nowak wrote:
> On 01/10/2015 01:52 PM, Jacob Carlborg wrote:
>> On 2015-01-10 13:36, Martin Nowak wrote:
>>
>>> The idea isn't bad, but the performance will suck. This is 
>>> generally
>>> known as N+1 query, only that this is even worse, as each 
>>> field is
>>> queried individually.
>>
>> Since the "all" method was called I would assume all rows in 
>> the person
>> table are fetched in one single query. Although I don't know 
>> if that
>> will work if not the whole row should be loaded.
>
The issue is not with the rows returned, but the columns (or 
object properties - which may map to multiple tables or be 
derived in some other way). Which rows need to returned is 
determined by some type of filtering mechanism, which is not an 
issue because that (logically) has to be explicit. The issue is 
determining which properties (for each "row") actually need to be 
returned without the need to explicitly request them (the data is 
already implicit within the user code itself).
>
>>
>>> Here is a sketch for an optimal solution. I'm actually 
>>> eagerly waiting
>>> that someone finally implements it.
>>>
>>> http://dpaste.dzfl.pl/cd375ac594cf
>>
Martin, that is brilliant! It seemed like all the pieces where 
there, I just couldn't put them together. I'm glad I'm not the 
only one thinking about this.

I have never been able to find an ORM (in any language) that 
comes close to working for us. We are currently looking into 
switching off PHP and the front runner is C# because it's a safe 
bet, we run Windows, and some people are sold on the concept of 
Entity Framework. Entity is (or was) built in to the .NET so they 
could theoretically do some neat tricks like compile query logic 
at compilation, and infer what data is actually needed by the 
program (the issue being discussed). Turns out they do query 
caching, but that's about it.

I'm not sure I can sell the idea of D (this is a very small and 
conservative group). I would also have to sell the idea of 
writing an ORM which is certainly not on the roadmap, but this 
will certainly help my argument.

Oh, we will also need a good SQL Server library which, to my 
knowledge, D is lacking. This is going to be a hard sell...


-Dave