Hi Julian,
Thanks for your good suggestion.
The idea of delayed freeze sounds reasonable to me, and it provides more
flexibility.
I also like the idea of an output report which is helpful for performance
diagnostics.
Best,
Liya Fan
On Fri, Sep 25, 2020 at 7:39 AM Julian Hyde wrote:
> Would it
Would it make sense to delay the 'freeze'? E.g. receive 1,000 requests
(as measured using an AtomicInteger) and then freeze the
JaninoRelMetadataProvider. That way, tests would not be competing with
each other.
Similarly, in production, you could create a production instance of
JaninoRelMetadataPr
Hi Julian,
Thank you for the feedback and good suggestions.
The idea of lazy load is reasonable. However, the testing of this feature
is still tricky, because:
1. When we have changed the flag, all subsequent test cases are all also
affected (many components of JaninoRelMetadataProvider are decla
CALCITE-3901 looks like a reasonable approach. I like the idea that it would
throw and tell you the classes and metadata types that you have missed.
The packaging in 3901 isn’t great. I don’t believe that the test needs to read
a system property and not even via the CalciteSystemProperty mechan
Hi Enrico,
We have also observed the problem.
Janino compilation is time consuming. For each single Java class, it takes
tens of milli-seconds.
Moreover, the compilation will take place multiple times, because:
1. We have multiple types of metadata.
2. The class for a particular type of metadata
Hi,
I am seeing that JaninoRelMetadataProvider is quite expensive, at least for
the "boostrap" phase of the system.
It is a cool piece of software and it is working well, but in some cases
probably it could be quite overkill, for instance in test cases of
applications that mostly run only one quer
