When running a selection, compiling the expression into a code object
so that it does not need to be re-parsed per every iteration.
Since it saves one parse per iteration, the gains become more
noticeable as the size of the relations grow.
In case of multiple renames, all of the resulting relations will point
to the same data, so writing on one and marking its only known copy
as writable would be incorrect.
For this to work, all the references should be kown to all the other
instances.
It is probably not worth to implement it.
Implemented test for the update
In case of a rename, the original relation and the resulting relations
are pointing to the same set.
In case of functions that change the relation, such as insert, a copy is
created to be able to write on it. But when writing on the other relation
a new copy would have been made too.
This fixes it, now when changing one relation, the other is marked as
writable as well.
When running relational as an .exe file generated by
py2exe, that line might give an exception. Because of
reasons.
I don't know what the hell is going on and I don't care.
Outer joins add the placeholder '---' that is used as some sort of NULL
value.
However select operations on such relations would always fail, because
relations are supposed to only contain values of class rstring, and
the placeholder was added as a regular string.
As a consequence, automatic casting would always fail, and the select
would always raise an exception.
Added a new test case with this specific case in mind.
This introduces several advantages:
No longer rely on the cache to be able to contain as many as
needed. It works within relational but it is not assured to be so if it
is used within other projects.
Using compile flags allows slightly simpler expressions.
Adds some functions to store and load an entire session as a binary
blob.
In this way the user does not need to re-load all the relations from the
previous session.
This is more Pythonic and makes the code more readable.
Backwards compatibility is provided by giving an alias with the
previous name of the class.
It will not be broken until the next major release.
Operations are possible even when the order of the attributes is
not the same. Because ordering is just an implementation detail and
not an actual part of relational algebra.
A _rearrange() function exists to convert relations to have a similar
format and be able to operate on them.
The function would perform a projection in any case, which would cause
the creation of a new temporary relation, even when the relations where
already using the same order of attributes.
This commit fixes the issue by making it return an identity if the
operation is not necessary.
When doing a selection, a new context (in the form of a dictionary)
is created.
Instead of re-using the same dictionary re-assigning the values, now
use a comprehension to avoid redundant reads.
In this way, checks are performed automatically on every tuple
and code is simplified.
This should make it safer to raise exceptions on files that are
not relations.
Rather than having a header class that contains a list of header,
change it to directly be an immutable tuple.
This simplifies the code because header can now be compared and
indexed like any other tuple.
Code had to be changed all over the place to cope with this new
datatype.
