Tobias
Tobias
Correct. With this new style the visitors itself return the copy and the caller could immediately put it in the right place. So you don't need to organise your copied...
Indeed this would be a massive api change. That is why we would go for version 4. If there are two visitor interfaces then we would need to visit methods...
@sivaraam: that is correct. As well this change does not support replacement by different types, e.g. **Column** to **literal** or **CaseExpression** or you name it. That is why I am...
So how to overcome this problems of the visitor pattern? Any ideas?
@AnEmortalKid That would be a possibility. However, the difficulties are still there. Let us stick with our example of copying the hierarchy, then die proposed changes would do their job...
Right. One could build some kind of proxy for the visitor, that could keep track of the previous or parent object. So our replacement would be simple.
The problem is described in this discussion. What type to return? Or do you want to multiply one visitor by adding different context types?
Function creation or definition is not supported. In fact this is TSql and not Sql alone. JSqlParser is only a Sql parser .
Are you talking about the complete **create or replace function** construct or only about the SQL parts within it?
So you want to serializable the parse tree? Could give a concrete usecase?