numberoverzero / jsonquery Goto Github PK

As noted in the readme, this::

{
    "column": "name"
    "operator": "like"
    "value": {
        "operator": "or",
        "value": [
            "Bill",
            "Mary",
            "Steve"
        ]
    }
}

is much more readable than this::

{
    "operator": "or",
    "value": [
        {
            "column": "name",
            "operator": "like",
            "value": "Bill"
        },
        {
            "column": "name",
            "operator": "like",
            "value": "Mary"
        },
        {
            "column": "name",
            "operator": "like",
            "value": "Steve"
        },
    ]
}

By collapsing the redundant information (column and operator) the intent is much more readable.

Concerns while implementing:

• What's the information propagation limit for values? The above is an easy choice, but what if one of those values wasn't a string, but another node?
• Can nodes overwrite operator values defined above? What if in the first snipped the user wants to use the like operator for 11 names but then use ilike the operator for "Mary"? Could they make the element a node that overrides operator, or do they have to nest the above in another OR to include the field?

http://jsonquery.readthedocs.org/, that is

Refactor the hardcoded type mappings to support arbitrary type/operator/function sets.

This doesn't need to use import magic to load extensions that are defined in some odd place. A simple solution could involve a global function on the module::

def add_type_mapping(column_type, opfunc_map):
    TYPE_OPERATORS[column_type] = opfunc_map

Important: This will require formalizing what the call signature is for a function defined in opfunc_map. Currently it works out that it be a function that takes in column and value and returns a criteria on that column (for that value) but this should be spelled out somewhere.

Only supporting String and Integer is kind of embarrassing.

The following types (and their public bases, if any) are available:

Generic Types

BigInteger (Integer)
Boolean ()
Date ()
DateTime ()
Enum (String)
Float (Numeric)
Integer ()
LargeBinary ()
Numeric ()
PickleType (alias of LargeBinary)
SchemaType ()
SmallInteger (Integer)
String (Concatenable)
Text (String)
Time ()
Unicode (String)
UnicodeText (Text)

SQL Standard Types

They all map to generic types above except for BINARY and VARBINARY which map to _Binary (protected). These won't be supported.

I don't intend to support all of these - for the first round, the following will be added:

Boolean
Date
DateTime
Numeric
Time

Once these are implemented, all of the following will be usable:

BigInteger
Boolean
Date
DateTime
Enum
Float
Integer
Numeric
SmallInteger
String
Text
Time
Unicode
UnicodeText

The following will not be usable:

LargeBinary
PickleType (alias of LargeBinary)
SchemaType

These likely won't see support until there's a pluggable framework in place for extending built-in column definitions.