Calling queries must be dropped before or at the same time that their called subqueries are dropped

#1

The documentation has the note below regarding dropping queries. Is there a technical reason that calling queries must be dropped first?

The GSQL language will refuse to drop an installed query Q if another query R is installed which calls query Q . That is, all calling queries must be dropped before or at the same time that their called subqueries are dropped.

#2

Q depend on R, if we allow R to be dropped first, then Q becomes invalid after R is dropped. This dependency relationship requires we need to drop all R’s dependent queries first, before we can drop R.

#3

Thanks! I do understand that Q will not work once R is dropped. My question really is “Will Q start working again once R is installed again if Q is not dropped first?”. As an extreme example, a very basic query R is used in 100 other queries. Every time I update R (drop R and install R), I would have to drop the other 100 queries and reinstall them as well. Is this technically necessary?

2 Likes
#4

Hi Jim,

This is a valuable feedback. Technically, if you want the best performance, this is a must, since each query is compiled into one binary, not calling a library which may have overhead.

I have created an internal ticket to address this issue. Currently, you have to drop all dependent query and then recompile them if you change R.

1 Like
#5

Just as an FYI, the order here is that the calling queries (the outer queries) must be dropped before the called queries (the inner queries). So, things never stop working.