Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Nested having doesn't work #360

Closed
SonicGD opened this issue Apr 10, 2020 · 2 comments
Closed

Nested having doesn't work #360

SonicGD opened this issue Apr 10, 2020 · 2 comments

Comments

@SonicGD
Copy link

SonicGD commented Apr 10, 2020

Hello. I found a problem in building query with nested having conditions. For example:

new Query().From("Foo").Select("Id")
                .Having(q => q.Having("bla", ">", 1).OrHaving("bla", ">", 2));

compiles to

SELECT "Id" FROM "Foo" HAVING

The problem is in CompileNestedCondition method cause it check for where component:

protected virtual string CompileNestedCondition<Q>(SqlResult ctx, NestedCondition<Q> x) where Q : BaseQuery<Q>
        {
            if (!x.Query.HasComponent("where", EngineCode))
            {
                return null;
            }

            var clauses = x.Query.GetComponents<AbstractCondition>("where", EngineCode);

            var sql = CompileConditions(ctx, clauses);

            return x.IsNot ? $"NOT ({sql})" : $"({sql})";
        }

If i change it to check current condition type, eg:

protected override string CompileNestedCondition<Q>(SqlResult ctx, NestedCondition<Q> x)
        {
            if (!x.Query.HasComponent(x.Component, EngineCode))
            {
                return null;
            }

            var clauses = x.Query.GetComponents<AbstractCondition>(x.Component, EngineCode);

            var sql = CompileConditions(ctx, clauses);

            return x.IsNot ? $"NOT ({sql})" : $"({sql})";
        }

sql generates correctly:

SELECT "Id" FROM "Foo" HAVING ("bla" > 1 OR "bla" > 2)

I can send PR if this is right way to fix this.

@ahmad-moussawi
Copy link
Contributor

@SonicGD it was intentionally kept to use the Where methods, since they are more flexible and supports many overloads. maybe this should be clear in the documentation.

@ahmad-moussawi
Copy link
Contributor

Documentation updated, thanks for your feedback

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants