ToExpressionNode method causes "stack overflow" exception. about serialize.linq HOT 14 CLOSED

@esskar, in our QueryProvider we have used the following transformation:
https://github.com/linq2db/linq2db/blob/master/Source/LinqToDB/Linq/Builder/ExpressionBuilder.cs#L297
It works very well for such big filter conditions.
Exactly before serialization, just transform expression.

from serialize.linq.

Could you please attach a code snippet representing your expression?

I doubt there will be an easy fix for this though. This behavior is actually expectable.

from serialize.linq.

as @vsoldatkin stated: we need the original expression that causes that error.
But it looks like you should rethink your expression
x.Account >= 799 && x.Account <= 0 seems to be an alternative here

from serialize.linq.

@vsoldatkin @esskar , thanks for reply.
I have a collection, the collection could contain guid or string or something else type data , for example,
x=>collection.contain(x.Id) , I want to send this expression from asp.net mvc client to wcf server, so i need serialize this expression, but collection cannot pass to server, so I modify it to x.Id=='constant value1 from collection' || x.Id=="**" ... , by this method, the collection's data can be passed to server, the wcf server accepts the expression ,and then passes it to nhibernate.
In asp.net mvc environment , when the collection has 800 objects , then invoke "ToExpressionNode", the statck overflow exception will appear.
In console environment , when the collection has 5000 objects , then invoke "ToExpressionNode", the statck overflow exception will appear.
I estimate that it has relationship with the thead's stack size. this is my code, thanks.

class Program
    {
        static void Main(string[] args)
        {
            IList<Guid> idCollection = new List<Guid>();
            for (int i = 0; i < 5000; i++)
            {
                idCollection.Add(Guid.NewGuid());
            }

            var propertyInfo = typeof(User).GetProperty("Id");
            var userParam = Expression.Parameter(typeof(User), "x");
            var propertyExpression = Expression.Property(userParam, propertyInfo);
            Expression composedExpression = Expression.Constant(false, typeof(bool));

            for (int i = 0; i < idCollection.Count; i++)
            {
                Expression equalExpression = Expression.MakeBinary(ExpressionType.Equal, propertyExpression, Expression.Constant(idCollection[i]));
                composedExpression = Expression.MakeBinary(ExpressionType.OrElse, equalExpression, composedExpression);
            }
            var expressionNode = composedExpression.ToExpressionNode();

        }
    }
    class User
    {
        public Guid Id
        {
            get;
            set;
        }
    }

from serialize.linq.

not sure if i want to support this.
i am build the expression tree using recursion, to change it, i would need to build my own stack; i have to evaluate if it is worth it

from serialize.linq.

idea: special collections where the values get serialized when used in expressions!?

or an extension method like

public static void MarkAsConstant(this object) { ... }

so i could mark a variable and when this variable gets used in an expression, we serialise the values like i do for other constant variables

from serialize.linq.

There is a quick method to linearize the algorithm by spawning Tasks in NodeFactory.Create. It adds a huge overhead without asyncs and a not-so-huge overhead using asyncs. But the latter is incompatible with SL version. I've implemented it as a proof of concept. See vsoldatkin/Serialize.Linq@c2ebe74

I'm afraid it might be neccessary to finally redesign the algorithm introducing custom stack-like "task" storage, probably on a NodeFactory level.

from serialize.linq.

Thanks for that.
Yet i thought about a new NodeFactoy implementation, but i was to busy to actually do it.
Maybe on the weekend.

from serialize.linq.

Wouldn't it perhaps be better (both architecturally and as a feature that benefits more than the fringe 800 expression case) to instead support a .WhereIn()/IndexOf().

Or perhaps (if not) supported (otherwise encourage usage of) an expression similar to (from n in p where (from o in list select o).Contains(n.prop) select n);

from serialize.linq.

i started a new branch for that (https://github.com/esskar/Serialize.Linq/tree/feature/non_recursive). the idea works, but some unit tests are borked

from serialize.linq.

@sdanyliv thanks. will look at it.

from serialize.linq.

@sdanyliv i looked further into your suggestions. do i need to adopt only your referenced function or do i also need to implement the Transform extension. i understand, that the Transform extension applies the transformation function first, and if the result does not differ, goes on with the actual transformation.

never mind.

from serialize.linq.

fixed with version 1.7.1
thanks for the help

from serialize.linq.

URW, it was long way until we invented acceptable solution, so i’m glad it helped someone else.

from serialize.linq.