``` @SqlMarker object SQLBuilder { fun query(i...

# announcements

[mingkangpan]

@SqlMarker
object SQLBuilder {
    fun query(init: SqlSelectBuilder.() -> Unit): SqlSelectBuilder {
        val builder = SqlSelectBuilder()
        builder.init()
        return builder
    }
}

I have this, but somehow the compiler still let me do this eventough I marked it with DSLMarker

val query = SQLBuilder.query {
        
        query { 
            
        }

what am I doing wrong? 😞

[karelpeeters]

Can you share a full (compilable) code sample?

[mingkangpan]

https://github.com/willhaben/kotlindsl

[mingkangpan]

there is module called sqlbuilder

[karelpeeters]

Yikes that code just screams "SQL injection"

[mingkangpan]

yes, it should only demonstrate kotlin DSL, it wont be some serious production code anyway

[karelpeeters]

I'd still recommend you to find a better example 🙁

[karelpeeters]

That code works fine for me, are you sure you didn't accidentally statically import the query function?

[karelpeeters]

(I mean the compiler rejects that code)

[karelpeeters]

Do you have something like this at the top of your test file? import com.minki.sqlbuilder.SQLBuilder.query

[mingkangpan]

yes, in my main file

[karelpeeters]

Then that's the problem simple smile

[mingkangpan]

I see, but I can still do something like this

select {
            select { 
                
            }

eventough I have this

@SqlMarker
class SqlSelectBuilder

[karelpeeters]

That's because your forgot @SqlMarker on the Select class.

[mingkangpan]

another question out of curiosity: if I mark Condition with @SqlMarker, I still can do this:

or {
     or { }
}

why?

[karelpeeters]

Because the first or brings an explicit new Condition into scope, which you then call the second or on.

[mingkangpan]

brings an explicit new what do you mean exactly by that? because I construct a new object?

[karelpeeters]

So the purpose of @DslMarker is to prevent receivers from the upper scopes being accidentally visible in the more nested scopes.

where { //1
    or { //2
        or { //3

1 calls its lambda with a Condition scope, and on that scope you call or 2. Then 2 calls its lambda with a new Condition receiver, and on that new receiver you can still call or. 2's lambda shouldn't be able to access 1's Condition, and indeed it can't, it uses 2's Condition instead.

[karelpeeters]

Note that it's not about creating a new object, you could just keep passing the same Condition object in the or code and it'd still work the same. This is a compile-time thing, not a runtime thing.

[mingkangpan]

I get it, very good explained, thank you and kudos

[karelpeeters]

You're welcome!

[karelpeeters]

(I still think they should take down that blog post or at least put a big disclaimer on it)

[mingkangpan]

I added a comment in my code to not take sql string literal generation as decent practice