If we had proper version definition and not placeholders, maybe you could rebuild module selectively and not the whole thing everytime something changes ? 🙂

I'm personnaly maintaining a forked of pinot where I apply

mvn -f src/pom.xml --batch-mode release:update-versions -DdevelopmentVersion=0.5.0-SNAPSHOT

and it just makes life easier when recompiling.

Don’t be so selfish @User, spread the kindness 😛

dhaha! It will impact the release proccess and I haven't taken the time to assert the impact of moving to fixed version in all our poms 😉 That's in my backlog

i also find it painful that we cant compile a single module anymore, I am sure we were able to do this

A design doc for inconsistency problems around time boundary calculation in pinot brokers: https://docs.google.com/document/d/1KykbUIstFI7F4IOOlUVnXWzpgKazwRAJdok0RT1ae64/

please review and leave your comments.

Thanks @User

looks simple, please add a test case

Routing table should be same got PQL as well as SQL, right? If so, we don't need a new endpoint.

hmm, its better to keep it separate so that we can deprecate the previous one

the compilers are different

I guess my question was for what query would PQL and SQL result in different routing tables?

it wouldn't but pql parser may not be able to compile the query

I see

This PR's travis build https://github.com/apache/incubator-pinot/pull/5796 is repeatedly failing with the following error:

Uploading reports
    url: <https://codecov.io>
    query: branch=master&commit=82d5cd333f30dfd404011b4b21c176697e02a92a&build=18227.2&build_url=&tag=&slug=apache%2Fincubator-pinot&yaml=.codecov.yml&service=travis&flags=&pr=5796&job=714640980
    -> Pinging Codecov
    -> Uploading to S3 <https://storage.googleapis.com/c>
    -> View reports at <https://codecov.io/github/apache/incubator-pinot/commit/0a6b0ce7b22a2ea8417d72dea22ecd0ad9b9a9fe>
+exit 0
The command "./.travis/.travis_test.sh" exited with 0.
before_cache
0.05s$ rm -rf $HOME/.m2/repository/org/apache/pinot
store build cache
0.00s
The job exceeded the maximum time limit for jobs, and has been terminated.

I have rerun it like 4 times

and no luck

@User ran all the tests locally as well and it's all good

anyone else seen this problem?

The PR simply moves around a bit of code

Thanks @User

I have been running into intermittent failures lately. It takes 2-3 re-runs for them to pass

We’ve also seen test failure during the travis code coverage stage.

And yes, I saw the same code-coverage related issue with my latest run (it passed on re-run)

Yes, sometimes the code coverage upload also fails (like it is currently failing for Neha's PR).

I have a fix for codecov

I will separate to another PR