For multi-line and single-line. After the change with the assignment
they are basically the same and there was no longer need
to have them separate in two functions.
It was not really easy to write the name for the result
in a separate box, and it would create a lot of garbage
results, by creating a new one per every query.
Now single lines queries can contain assignments, and if not
a default relation named 'last_' is used to hold the last result.
In the UI, a common pattern was to check if a query was
prefixed by an assignment and in that case, assign the result
to the given name.
This function puts this in a common place, so it can be used from
all the parts where it is needed.
It was a bit buggy and was not blurring all the widgets, or
not reverting the blur properly. Probably best to just show a
label instead.
Still, the proper solution would probably be to do the processing
in a separate thread.
Before the processing of a query starts, it will blur the UI.
This gives feedback to the user that something is happening, and is
simple to implement because I am too lazy to move the processing in
a separate thread.
This uses the CallableString object only in the final step and not
during all the intermediate ones.
Since str is a native object, it is faster to use than a normal
object.
This is a very marginal optimization that will not yield any
gains :)
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
Require them to have assert rather than testing the
result variables set.
This makes for way simpler code.
Now also prints stacktrace to know where the problem occurred.
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.
Salvo 'LtWorf' Tomaselli