Github user felixcheung commented on the issue:
https://github.com/apache/zeppelin/pull/2428
merging if no more comment
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled
Github user astroshim commented on the issue:
https://github.com/apache/zeppelin/pull/2428
LGTM~
I think this PR can be merged.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this
Github user herval commented on the issue:
https://github.com/apache/zeppelin/pull/2428
ping - please advise
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes
Github user herval commented on the issue:
https://github.com/apache/zeppelin/pull/2428
Rebased to latest master - please advise
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
Github user herval commented on the issue:
https://github.com/apache/zeppelin/pull/2428
any additional thoughts on this? Is it mergeable? @khalidhuseynov
@tinkoff-dwh @felixcheung
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub
Github user herval commented on the issue:
https://github.com/apache/zeppelin/pull/2428
I am using the original setting (getMaxResults). I had to set it in two
calls because setFetchSize will determine that there is a ânextâ page, but
if I only do âsetMaxResultsâ, it will not
Github user felixcheung commented on the issue:
https://github.com/apache/zeppelin/pull/2428
got it. I agree it's generally better to restrict the job at the source
perhaps you can use the existing settings but apply it at the JDBC instead?
it would be easier to switch existing
Github user herval commented on the issue:
https://github.com/apache/zeppelin/pull/2428
@tinkoff-dwh it's not duplicate. The bug here is that if you don't do
`statement.setMaxRows`, some drivers (eg postgres) will try to load everything
when you issue a `select *`. Using
Github user tinkoff-dwh commented on the issue:
https://github.com/apache/zeppelin/pull/2428
we already have a check to limit. setMaxRows duplicate it
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does
Github user masyan commented on the issue:
https://github.com/apache/zeppelin/pull/2428
we already have a check to limit. setMaxRows duplicate it
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not
Github user herval commented on the issue:
https://github.com/apache/zeppelin/pull/2428
---
If your project is set up for it, you can reply to this
Github user herval commented on the issue:
https://github.com/apache/zeppelin/pull/2428
hmm.. It actually seems that setFetchSize does not limit the query
execution (so it takes forever & hangs Zeppelin)
Figuring out if there's a way to show results are truncated + use
Github user tinkoff-dwh commented on the issue:
https://github.com/apache/zeppelin/pull/2428
@herval
reopen pull request. and wait another reviewers or committers)
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If
Github user tinkoff-dwh commented on the issue:
https://github.com/apache/zeppelin/pull/2428
LGTM
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if
Github user tinkoff-dwh commented on the issue:
https://github.com/apache/zeppelin/pull/2428
failed test wich load dependencies, it is possible too long or problems
with the network. try restart again
---
If your project is set up for it, you can reply to this email and have your
Github user herval commented on the issue:
https://github.com/apache/zeppelin/pull/2428
@tinkoff-dwh build #3 is failing in both my master & zeppelin master:
https://travis-ci.org/apache/zeppelin - restarting didn't make it pass:
https://travis-ci.org/apache/zeppelin/jobs/246113686
Github user tinkoff-dwh commented on the issue:
https://github.com/apache/zeppelin/pull/2428
https://travis-ci.org/herval/zeppelin/builds/245889847
try restart 3 and 5 job
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as
Github user herval commented on the issue:
https://github.com/apache/zeppelin/pull/2428
It seems apache/zeppelin master (which is what this branch is based on) is
failing the build - should I rebase it to 0.7 instead, or wait for master to be
fixed? Please let me know what should I
Github user tinkoff-dwh commented on the issue:
https://github.com/apache/zeppelin/pull/2428
yep, getMaxResult is correct. i thought the condition <=
```while (displayRowCount < getMaxResult() && resultSet.next())```
and last next() will request the next part (fetchSize)
---
Github user herval commented on the issue:
https://github.com/apache/zeppelin/pull/2428
Why +1?
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the
Github user tinkoff-dwh commented on the issue:
https://github.com/apache/zeppelin/pull/2428
I think it's impossible to test.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
Github user tinkoff-dwh commented on the issue:
https://github.com/apache/zeppelin/pull/2428
it would be better getMaxResult() + 1
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this
Github user herval commented on the issue:
https://github.com/apache/zeppelin/pull/2428
I'm also not exactly sure how to write a test for this, as the
JDBCInterpreterTest doesn't use anything in the line of mocks (and the outside
behavior - limiting the number of returned rows - is
Github user herval commented on the issue:
https://github.com/apache/zeppelin/pull/2428
@tinkoff-dwh you're right, picked the wrong method - using setFetchSize now
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your
Github user tinkoff-dwh commented on the issue:
https://github.com/apache/zeppelin/pull/2428
user will not know that the table has more rows and the result is not
complete. Maybe set fetchSize?
---
If your project is set up for it, you can reply to this email and have your
reply
25 matches
Mail list logo
