This post to get users opinion regarding the content of the graph :
1-Should the graph be simplified as today: to display the columns with predicates and aggregates / order by clauses (without any function), to be a kind of ER diagram
or
_2-Should the graph be as close as possible to the SQL: with to_date, case, concat … functions displayed as arithmetic opérations and other details/i]
Regards
PAscal_
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Technically, there is function splitByCommasWithoutParens(). It is used to separate aliases for columns (while discarding the formulas). If called upon the original SQL, it migth even work ..
But there is need for substantial changes. Currently the Simplifier is invoked before splitByCommasWithoutParens(). Parsing would fail without prior simplification
-Alex
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Would it be enough to show formulas for joins ? If you think about huge SELECTS over tens of tables, there is little sense to show all columns and variations A, A+1, B, B+2, C, 'Mr' || C, etc
-Alex
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Initial need if for joins …
but for filters also (and today's meaning is wrong if simplified, returns A='2' for f(A)='2' or A=g('2') …)
and finally for projections also (when field is coming from a subquery joined at the outer level).
If simply keeping original text is not easy,
what about the second alternativ:
field name becomes x! or '2'! when used with a function or an arithmetic operation ?
Regards
PAscal
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Adding +"_" like
func.setParseAction(lambda x: x.pre + " " + x.inner.replace(',', '+') +"_" )
in buildRemovers, adds an "_" at the end of each column where there was a function
Doesn't works with "!' nor "@"
Seems effectively much more complicated for other operands :f('1'), a||b, a||' str', case, arithmetic operations …
Regards
PAscal
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I am working to fix the other open issues before starting the big work. Simplifier should be called from SingleSelect (nto before as now). That also means that almost all test cases must be rewritten.
Now looking at reducign extra long IN clauses .
-Alex
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
This post to get users opinion regarding the content of the graph :
1-Should the graph be simplified as today: to display the columns with predicates and aggregates / order by clauses (without any function), to be a kind of ER diagram
or
_2-Should the graph be as close as possible to the SQL: with to_date, case, concat … functions displayed as arithmetic opérations and other details/i]
Regards
PAscal_
Hi,
Technically, there is function splitByCommasWithoutParens(). It is used to separate aliases for columns (while discarding the formulas). If called upon the original SQL, it migth even work ..
But there is need for substantial changes. Currently the Simplifier is invoked before splitByCommasWithoutParens(). Parsing would fail without prior simplification
-Alex
And what about :
keeping a track on the graph (adding "!" for example) to the field or the constant where a function has been removed ?
This applying for f(a), f('1'), a||b, a||' str', case, arithmetic operations +,-,*,/ like a+b, a+1 …
Regards
PAscal
Hi,
Would it be enough to show formulas for joins ? If you think about huge SELECTS over tens of tables, there is little sense to show all columns and variations A, A+1, B, B+2, C, 'Mr' || C, etc
-Alex
Initial need if for joins …
but for filters also (and today's meaning is wrong if simplified, returns A='2' for f(A)='2' or A=g('2') …)
and finally for projections also (when field is coming from a subquery joined at the outer level).
If simply keeping original text is not easy,
what about the second alternativ:
field name becomes x! or '2'! when used with a function or an arithmetic operation ?
Regards
PAscal
For private usage
Adding +"_" like
func.setParseAction(lambda x: x.pre + " " + x.inner.replace(',', '+') +"_" )
in buildRemovers, adds an "_" at the end of each column where there was a function
Doesn't works with "!' nor "@"
Seems effectively much more complicated for other operands :f('1'), a||b, a||' str', case, arithmetic operations …
Regards
PAscal
I am working to fix the other open issues before starting the big work. Simplifier should be called from SingleSelect (nto before as now). That also means that almost all test cases must be rewritten.
Now looking at reducign extra long IN clauses .
-Alex