or using the positional shorthand:

Relation(['SNO', 'SNAME', 'STATUS', 'CITY'],
         [('S1', 'Smith', 20,       'London'),
          ('S2', 'Jones', 10,       'Paris'),
          ('S3', 'Blake', 30,       'Paris'),
          ('S4', 'Clark', 20,       'London'),
          ('S5', 'Adams', 30,       'Athens'),
         ]
        )

Relations can be assigned to relvars, e.g.

S = Relation(['SNO', 'SNAME', 'STATUS', 'CITY'],
             [('S1', 'Smith', 20,       'London'),
              ('S2', 'Jones', 10,       'Paris'),
              ('S3', 'Blake', 30,       'Paris'),
              ('S4', 'Clark', 20,       'London'),
              ('S5', 'Adams', 30,       'Athens'),
             ],
             {'PK':(Key, ['SNO'])}
            )

Key is shorthand for a key constraint

RESTRICT and EXTEND are implemented in terms of AND and use anonymous functions to define the expressions, e.g.:

RESTRICT(S, lambda t: t.STATUS == 20)

In this example, the 'lambda' keyword declares a function that is passed to the RESTRICT function and it introduces a range variable, 't', which will stand for each tuple in the relation S. The expression itself, the part after the colon, tests whether the STATUS attribute of each tuple is equal to 20: if it returns 'True' then the tuple is included in the result.

Any Python expression can be passed this way. So here, complex boolean expressions including boolean operators and function calls can be built, e.g.

RESTRICT(S, lambda t: 10 < t.STATUS < 30 and t.SNAME.startswith('C'))

This was made easy because of Python's ability to pass functions around as first-class objects.

Implemented using AND and relationFromCondition

The lambda function passed to the EXTEND function should return a tuple, so for example:

EXTEND(S, lambda t: {'INITIAL':t.SNAME[:1]})

Implemented using AND and relationFromExtension

The operators associated with the Relation class are overridden to give a natural Python-like (Pythonic) syntax, e.g.

r1 == r2           #equality
r1 != r2           #inequality
r1 <= r2           #subset
r1 < r2            #proper subset
r1 >= r2           #superset
r1 > r2            #proper superset
t1 in r1           #relation (and tuple) membership
t1 not in r1       #relation (and tuple) exclusion
r1(['a1', 'a2'])   #projection
r1 & r2            #AND, i.e. intersection or natural join or Cartesian join
r1 | r2            #OR, i.e. union
r1 - r2            #MINUS

'&' meaning depends on how many attributes are shared

Building on the Relation's extend, project and remove methods, we have:

def WRAP(r, Hr, wrapname):
    """Wrapping (macro)"""
    return r.extend(lambda t: {wrapname:t.project(Hr)}).remove(Hr)

The power of Python really shines through when building functions such as WRAP and UNWRAP, which in most languages would be lengthy and bug-prone, in just a line or two of code (also helped by bootstrapping the higher-level D)

And here's a definition of a recursive relational operator:

def TCLOSE(r):
    """Transitive closure (an example of a recursive relational operator)
       (macro) (not optimised for speed)
    """
    if len(r.heading) != 2:
        raise InvalidOperation("TCLOSE expects a binary relation, "
                               "e.g. with a heading ['X', 'Y']")

    _X, _Y = r.heading
    TTT = r | (COMPOSE(r, r.rename({_Y:'_Z', _X:_Y})).rename({'_Z':_Y}))
    if TTT == r:
        return TTT
    else:
        return TCLOSE(TTT)

S.where(lambda t: IMAGE(SP)(['PNO']) == P(['PNO']))

S.extend(lambda t: {'TOTQD':SUM(IMAGE(SP)(['QTY']))})

IMAGE replaces DIVIDE and SUMMARIZE in the next version.

and also removes the 'IZE' spelling issue

Virtual relvars (views) can be created using lambda to defer the evaluation of relational expressions. For example:

r3 = r1 & r2

immediately evaluates the expression on the right hand side and assigns the result to r3. Whereas:

r3 = View(lambda: r1 & r2)

initial version re-used Relation class and passed headings, e.g Relation(['r1a1', 'r2a1'], lambda: r1 & r2)

assigns the expression r1 & r2 to the View r3 which will then be re-evaluated each time the value of r3 is needed.

The View class inherits from Relation.

no view updates... yet

Insert and delete methods are available for the Relation class and have been set to override Python's |= and -= update in-place operators, so the following could be used to insert or delete relations (or tuples):

r1 |= r2            #insert (union update in-place)
r1 -= r2            #delete (minus update in-place)

Also an update method is available which takes two lambda expressions: one to select which tuples to update and one to say how to update those tuples, e.g.

r1.update(lambda t: t.a1 == 5, 
          lambda u: {'a1':0})

would update each tuple in r1 that had a1 == 5 and set a1 to 0. Of course, the update is just a shorthand for a delete followed by an insertion.

We can use Python generators to provide tuples for a virtual relation.

Example: define a generator, plus_gen, and wrap it in a virtual relvar, plus:

def plus_gen(x=None, y=None, z=None):
    "Plus generator yielding tuples. Could just as well be called minus_gen"
    if x is not None and y is not None and z is None:
        yield {'x':x, 'y':y, 'z':x + y}
    elif x is not None and y is None and z is not None:
        yield {'x':x, 'y':z - x, 'z':z}
    elif x is None and y is not None and z is not None:
        yield {'x':z - y, 'y':y, 'z':z}
    elif x is not None and y is not None and z is not None:
        if x + y == z:
            yield {'x':x, 'y':y, 'z':z}  #i.e. True
        #else yield nothing, i.e. False
    else:
        #Note: we could go further and return tuples given just one attribute
        #      or indeed we could start yielding infinite combinations if no 
        #      attributes are passed (but then non-relational?)
        raise InvalidOperation("Infinite rows")  #no pair of x,y or z

plus = View(plus_gen)

we take the heading from the function parameters

Such a 'generated relation' can be joined as usual, e.g.

Relation(["x", "y"], 
         [(7,   8), 
          (11, 23)]) & plus

And this can then be 'composed' with arguments, e.g. what's 3 + 4?:

COMPOSE(GENERATE({'x':3, 'y':4}), plus)

and so:

COMPOSE(GENERATE({'x':3, 'y':4}), plus).to_tuple().z

would return the value 7.

powerful (perhaps worth having a simpler syntax)!

perhaps develop meta idea here?

• Python 3 compatible

  • Python 3 has set literals, e.g. {1, 2, 3} so we can use this slightly better syntax, e.g.:

    Relation(['SNO', 'SNAME', 'STATUS', 'CITY'],
             {{'SNO':'S1', 'SNAME':'Smith', 'STATUS':20, 'CITY':'London'},
              {'SNO':'S2', 'SNAME':'Jones', 'STATUS':10, 'CITY':'Paris'},
              {'SNO':'S3', 'SNAME':'Blake', 'STATUS':30, 'CITY':'Paris'},
              {'SNO':'S4', 'SNAME':'Clark', 'STATUS':20, 'CITY':'London'},
              {'SNO':'S5', 'SNAME':'Adams', 'STATUS':30, 'CITY':'Athens'},
             }
            )
    

• Persistence plug-in with driver for SQLite/PostgreSQL etc.

plug-ins using SQL databases will have issues dealing with RVAs

• Database namespaces, e.g.

  db = Database()
  ...
  with db: db.R1, db.R2 = A, B
  

  to provide hooks for:

  • Persistence
  • Catalog
  • Constraint declaration & checking
  • Security declaration & checking
  • Atomic updates (which replace transactions)

a, b = c, d #RHS is evaluated first, then assignments are made

• Constraint inference (may need some help translating the original algorithm!)
  • Some straightforward ones are already done, e.g. after a rename or remove

• Updates via Views (help needed!)

• System keys

• N-adic versions of some of the functions. e.g.

  def AND(*args):
      for r in args:
          #etc.
  

gives good chance for join optimisation

• Use distributed-version-control mechanisms to persist locally and merge across nodes
  • Not suitable for all applications
  • Optimised data transfers
  • Handles network outage
  • Multi-versioned, with audit

This was proposed on the TTM mailgroup ([email protected]) 22/01/2010 "managing isolation with multi-versioning"

• 'Cloud' relations, e.g.

  r1 = Relation('http://example.com/r1')