dafeder / dkan-sql-parse Goto Github PK

Probably not a problem for most cases since most people don't bother to add their own alias and we are not yet supporting joins, but if an alias is provided for a resource, it still defaults "t" no matter what it is. So if we parse:

SELECT numcol FROM tablename x WHERE (numcol > 2)

We get this, where the resource added to the properties elsewhere in the query should be "x" but is always "t".

    "properties": [
        {
            "resource": "t",
            "property": "numcol"
        }
    ],
    "resources": [
        {
            "id": "tablename",
            "alias": "x"
        }
    ],
    "conditions": [
        {
            "resource": "t",
            "property": "numcol",
            "operator": ">",
            "value": 2
        }
    ]
}

(Cutting off some superfluous properties at the end of the JSON there.)

If we always use the alias explicitly it works just fine:

SELECT x.numcol FROM tablename x WHERE (x.numcol > 2)

parses to:

{
    "properties": [
        {
            "resource": "x",
            "property": "numcol"
        }
    ],
    "resources": [
        {
            "id": "tablename",
            "alias": "x"
        }
    ],
    "conditions": [
        {
            "resource": "x",
            "property": "numcol",
            "operator": ">",
            "value": 2
        }
    ]
}

This probably needs a significant refactor because we'd need to set a universal default table alias, and our static functions wouldn't be able to see it. So we'll need to make TreeTranslator a non-static class to fix this.

Would be a good idea to write unit tests here before moving into DKAN. They should be portable with the two translate classes.