Re: Release of Apache Phoenix 5.1.1 RC0
Shouldn't we wait for the related PHOENIX-6408 as well ? Istvan On Wed, Mar 10, 2021 at 1:51 AM la...@apache.org wrote: > I just committed PHOENIX-6402 > > Let's have another attempt at an RC for 5.1.1. > (Assuming all tests continue to pass) > > -- Lars > > > On Sunday, March 7, 2021, 3:30:46 PM PST, la...@apache.org < > la...@apache.org> wrote: > > > > > > I have a real fix ready in PHOENIX-6402. Let's wait for that and then do a > 5.1.1 release. > > > > > > > On Monday, March 1, 2021, 4:15:40 PM PST, la...@apache.org < > la...@apache.org> wrote: > > > > > > -1 (binding) > > See https://issues.apache.org/jira/browse/PHOENIX-6400 > I'm testing a bit more, but that looks wrong. > > -- Lars > > > > On Sunday, February 28, 2021, 7:32:09 PM PST, Xinyi Yan < > yanxi...@apache.org> wrote: > > > > > > +1 (non-binding) based on the signature, checksum and mvn clean > install/verify. > > > On Sun, Feb 28, 2021 at 4:59 AM Viraj Jasani wrote: > > > +1 (non-binding) > > > > Tested against HBase 2.4.1 (compiled with Hadoop profile 3.0) > > > > * Signature: ok > > * Checksum : ok > > * Rat check (1.8.0_171): ok > > - mvn clean apache-rat:check > > * Built from source (1.8.0_171): ok > > - mvn clean install -DskipTests > > * CRUD testing locally: ok > > * Unit tests pass (1.8.0_171): failed > > - mvn clean package && mvn verify -Dskip.embedded > > > > > > [ERROR] Failures: > > [ERROR] > > IndexToolForNonTxGlobalIndexIT.testBuildSecondaryIndexAndScrutinize:421 > > expected:<0> but was:<-1> > > > > [ERROR] Failures: > > [ERROR] > > > ViewTTLIT.testDeleteWithOnlyTenantView:1967->upsertDataAndRunValidations:2329->validateExpiredRowsAreNotReturnedUsingData:2390->verifyRowsBeforeTTLExpiration:2451 > > Rows upserted and fetched do not match, upserted=5, fetched=4 > > expected:<[00B0y01, 00B0y02, 00B0y03, > > 00B0y04, 00B0y05]> but was:<[00B0y01, > > 00B0y02, 00B0y03, 00B0y04]> > > > > > > Subsequent manual test runs went well: > > > > [INFO] Running org.apache.phoenix.end2end.IndexToolForNonTxGlobalIndexIT > > [WARNING] Tests run: 72, Failures: 0, Errors: 0, Skipped: 4, Time > elapsed: > > 1,010.964 s - in > org.apache.phoenix.end2end.IndexToolForNonTxGlobalIndexIT > > > > [INFO] Running org.apache.phoenix.end2end.ViewTTLIT > > [INFO] Tests run: 26, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: > > 772.233 s - in org.apache.phoenix.end2end.ViewTTLIT > > > > > > > > On 2021/02/27 00:51:06, Geoffrey Jacoby wrote: > > > +1 (binding) > > > > > > Check signatures and checksums: OK > > > apache-rat:check for licenses : OK > > > mvn clean install -DskipTests: OK > > > mvn verify for new 2.4.1 support: OK after rerunning one crashed test > > > > > > Geoffrey > > > > > > > > > On Fri, Feb 26, 2021 at 6:04 AM Istvan Toth wrote: > > > > > > > Please vote on this Apache phoenix release candidate, > > > > phoenix-5.1.1RC0 > > > > > > > > The VOTE will remain open for at least 72 hours. > > > > > > > > [ ] +1 Release this package as Apache phoenix 5.1.1 > > > > [ ] -1 Do not release this package because ... > > > > > > > > The tag to be voted on is 5.1.1RC0: > > > > > > > > https://github.com/apache/phoenix/tree/5.1.1RC0 > > > > > > > > The release files, including signatures, digests, as well as > CHANGES.md > > > > and RELEASENOTES.md included in this RC can be found at: > > > > > > > > https://dist.apache.org/repos/dist/dev/phoenix/phoenix-5.1.1RC0/ > > > > > > > > Maven artifacts are available in a staging repository at: > > > > > > > > https://repository.apache.org/#stagingRepositories > > > > (orgapachephoenix-1215) > > > > > > > > Artifacts were signed with the 0x794433C7 key which can be found in: > > > > > > > > https://dist.apache.org/repos/dist/release/phoenix/KEYS > > > > > > > > To learn more about Apache phoenix, please see > > > > > > > > http://phoenix.apache.org/ > > > > > > > > Thanks, > > > > Istvan > > > > > > > > > >
[jira] [Assigned] (PHOENIX-6399) Updating BackwardCompatibilityIT supported versions
[ https://issues.apache.org/jira/browse/PHOENIX-6399?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Istvan Toth reassigned PHOENIX-6399: Assignee: Istvan Toth (was: Xinyi Yan) > Updating BackwardCompatibilityIT supported versions > --- > > Key: PHOENIX-6399 > URL: https://issues.apache.org/jira/browse/PHOENIX-6399 > Project: Phoenix > Issue Type: Test >Reporter: Xinyi Yan >Assignee: Istvan Toth >Priority: Major > Fix For: 4.17.0, 5.2.0 > > > After the 4.16/5.1 release, we should add/update BackwardCompatibilityIT for > supported client versions. This will allow us to catch any backward > compatibilities in advance. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (PHOENIX-6399) Updating BackwardCompatibilityIT supported versions
[ https://issues.apache.org/jira/browse/PHOENIX-6399?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Xinyi Yan reassigned PHOENIX-6399: -- Assignee: Xinyi Yan > Updating BackwardCompatibilityIT supported versions > --- > > Key: PHOENIX-6399 > URL: https://issues.apache.org/jira/browse/PHOENIX-6399 > Project: Phoenix > Issue Type: Test >Reporter: Xinyi Yan >Assignee: Xinyi Yan >Priority: Major > Fix For: 4.17.0, 5.2.0 > > > After the 4.16/5.1 release, we should add/update BackwardCompatibilityIT for > supported client versions. This will allow us to catch any backward > compatibilities in advance. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (PHOENIX-6408) LIMIT on local index query with uncovered columns in the WHERE returns wrong result.
[ https://issues.apache.org/jira/browse/PHOENIX-6408?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lars Hofhansl updated PHOENIX-6408: --- Summary: LIMIT on local index query with uncovered columns in the WHERE returns wrong result. (was: LIMIT on local index query with uncovered columns in the WHERE returns wrong results.) > LIMIT on local index query with uncovered columns in the WHERE returns wrong > result. > > > Key: PHOENIX-6408 > URL: https://issues.apache.org/jira/browse/PHOENIX-6408 > Project: Phoenix > Issue Type: Sub-task >Affects Versions: 5.1.1, 4.16.1, 5.2.0 >Reporter: Lars Hofhansl >Assignee: Lars Hofhansl >Priority: Major > > Sorry one more issue. > In PHOENIX-6402 I fixed local indexes with uncovered columns in the WHERE > clause. > It turns out that LIMIT is also executed as a filter, so now that also needs > to change and be invoked after the extra filter. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (PHOENIX-6408) LIMIT on local index query with uncovered columns in the WHERE returns wrong results.
[ https://issues.apache.org/jira/browse/PHOENIX-6408?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lars Hofhansl updated PHOENIX-6408: --- Summary: LIMIT on local index query with uncovered columns in the WHERE returns wrong results. (was: LIMIT on local index query with uncovered columns in the WHERE returns wrong result.s) > LIMIT on local index query with uncovered columns in the WHERE returns wrong > results. > - > > Key: PHOENIX-6408 > URL: https://issues.apache.org/jira/browse/PHOENIX-6408 > Project: Phoenix > Issue Type: Sub-task >Affects Versions: 5.1.1, 4.16.1, 5.2.0 >Reporter: Lars Hofhansl >Assignee: Lars Hofhansl >Priority: Major > > Sorry one more issue. > In PHOENIX-6402 I fixed local indexes with uncovered columns in the WHERE > clause. > It turns out that LIMIT is also executed as a filter, so now that also needs > to change and be invoked after the extra filter. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (PHOENIX-6408) LIMIT on local index query with uncovered columns in the WHERE returns wrong result.s
Lars Hofhansl created PHOENIX-6408: -- Summary: LIMIT on local index query with uncovered columns in the WHERE returns wrong result.s Key: PHOENIX-6408 URL: https://issues.apache.org/jira/browse/PHOENIX-6408 Project: Phoenix Issue Type: Sub-task Affects Versions: 5.1.1, 4.16.1, 5.2.0 Reporter: Lars Hofhansl Assignee: Lars Hofhansl Sorry one more issue. In PHOENIX-6402 I fixed local indexes with uncovered columns in the WHERE clause. It turns out that LIMIT is also executed as a filter, so now that also needs to change and be invoked after the extra filter. -- This message was sent by Atlassian Jira (v8.3.4#803005)
Re: [DISCUSS] HBase 2.2.5 public maven artifacts are incompatible with Hadoop 3
Maybe we could try to see if we could make Async WAL work with both hadoop 2 and hadoop 3. But please do not rely on me, I'm not sure if I can make this done soon. Thanks. Andrew Purtell 于2021年3月7日周日 上午1:36写道： > Because the Async WAL module will not link with Hadoop 3 jars if it has > been compiled for Hadoop 2, Phoenix builds that download the Hadoop 3 and > HBase 2 jars from public repositories will not work. Tests cannot run > during the Maven verify phase because the minicluster will terminate with > linkage errors. To work around this Phoenix build instructions tell the > user to recompile HBase for Hadoop 3 and install it into the local Maven > cache first. > > To the extent Hadoop and HBase classes expecting to link with Hadoop 3 are > incorporated unshaded into the Phoenix server jar there is also risk of > real runtime problems in a deployment into a server classpath expecting and > including Hadoop 2. > > Publishing artifacts built against Hadoop 3 would be a solution but there > are a couple of risks. The first is the time and complexity of the release > candidate build and publish process will double. The second is Maven > classifiers somehow are not up to the task of distinguishing between > default and Hadoop 3 profile artifacts. The latter would be something we > can determine right away. The former would be potentially be a problem > every time an RM attempts a release. A nightly build for Hadoop 3 with > people actually paying attention and fixing failures there would mitigate. > > > > On Mar 5, 2021, at 5:37 AM, 张铎 wrote: > > > > The reason why we only publish artifacts compiled with hadoop 2 for > HBase > > is that, you can use these artifacts to run HBase against a 3.x HDFS > > cluster, no problem, you do not need to replace the hadoop jars in HBase > to > > hadoop 3, as we will not make use any new features at client side... > > > > I'm not sure the usage of phoenix, if it is necessary, I think we could > try > > to publish extra artifacts which are compiled against hadoop 3.x. > > > > Thanks. > > > > Istvan Toth 于2021年3月5日周五 上午1:40写道： > > > >> Hi! > >> Opened https://issues.apache.org/jira/browse/PHOENIX-6404 to track > this. > >> Istvan > >>> On Wed, Mar 3, 2021 at 11:34 PM Geoffrey Jacoby > >>> wrote: > >>> If the effort to support Hadoop 2 in Phoenix 5 isn't prohibitive, it > >> would > >>> be a huge help if we could do that. A couple different reasons: > >>> 1. Ease of development. The workaround described in BUILDING.md adds > >> extra > >>> friction to getting an environment setup, and it has to be redone for > >> each > >>> patch release of HBase an engineer needs to work with. It's confusing > for > >>> both new contributors and experienced ones who don't usually work with > >> 5.x > >>> or haven't lately. > >>> 2. Ease of upgrade. At my dayjob, we try to avoid upgrading > combinations > >> of > >>> Hadoop, HBase, and/or Phoenix at the same time to make upgrade testing > >> and > >>> debugging simpler. HBase 2.x and Phoenix 5.x have to be done in > lockstep, > >>> and there's no avoiding that. But since HBase 1.x doesn't support > Hadoop > >> 3, > >>> and Phoenix 5 doesn't support HBase 1.x or Hadoop 2, that means that an > >>> upgrade from any Phoenix 4 to any Phoenix 5 requires upgrading Hadoop, > >>> HBase and Phoenix to new major versions simultaneously. It would be > >> really > >>> nice to do HBase / Phoenix first, and then Hadoop later. > >>> Geoffrey > >>> On Wed, Mar 3, 2021 at 12:55 AM Istvan Toth > > >>> wrote: > Hi! > For the first part of your question: Yes, you are correct. > I think that there is no inherent technical issue that would make it > impossible to support Hbase 2 on Hadoop 2 for Phoenix. > While this happened before my time, I guess that supporting Hadoop 3 > >> only > was a decision that partly stemmed from the then current Phoenix maven > setup, > which wasn't equipped to support multiple profiles (see the multiple > branches for the HBase 1.x versions), and partly because this was the > configuration that > the implementers (Ankit, Josh, Rajeshbabu, Sergey) were interested in. > I don't know how much work and additional complexity it would take to > >> add > Hadoop2 support for master. > My guess is that it would need some major changes on the maven side > for > building, packaging, testing, and docs, > but probably little in the way of Java code changes. > It would also make providing binaries for Phoenix, connectors and PQS > >>> even > more hairy than now. > If anyone has more historical context, or a better idea of what it > >> would > take to do this, please let us know! > Istvan > On Tue, Mar 2, 2021 at 7:00 PM Viraj Jasani > >> wrote: > > Hi, > >> However, up to now, we could use these artifacts with Hadoop 3.0 > >> and > they > >> worked. (Or we just didn't hit the incompatibilities in our test >
Re: Release of Apache Phoenix 5.1.1 RC0
I just committed PHOENIX-6402 Let's have another attempt at an RC for 5.1.1. (Assuming all tests continue to pass) -- Lars On Sunday, March 7, 2021, 3:30:46 PM PST, la...@apache.org wrote: I have a real fix ready in PHOENIX-6402. Let's wait for that and then do a 5.1.1 release. On Monday, March 1, 2021, 4:15:40 PM PST, la...@apache.org wrote: -1 (binding) See https://issues.apache.org/jira/browse/PHOENIX-6400 I'm testing a bit more, but that looks wrong. -- Lars On Sunday, February 28, 2021, 7:32:09 PM PST, Xinyi Yan wrote: +1 (non-binding) based on the signature, checksum and mvn clean install/verify. On Sun, Feb 28, 2021 at 4:59 AM Viraj Jasani wrote: > +1 (non-binding) > > Tested against HBase 2.4.1 (compiled with Hadoop profile 3.0) > > * Signature: ok > * Checksum : ok > * Rat check (1.8.0_171): ok > - mvn clean apache-rat:check > * Built from source (1.8.0_171): ok > - mvn clean install -DskipTests > * CRUD testing locally: ok > * Unit tests pass (1.8.0_171): failed > - mvn clean package && mvn verify -Dskip.embedded > > > [ERROR] Failures: > [ERROR] > IndexToolForNonTxGlobalIndexIT.testBuildSecondaryIndexAndScrutinize:421 > expected:<0> but was:<-1> > > [ERROR] Failures: > [ERROR] > >ViewTTLIT.testDeleteWithOnlyTenantView:1967->upsertDataAndRunValidations:2329->validateExpiredRowsAreNotReturnedUsingData:2390->verifyRowsBeforeTTLExpiration:2451 > Rows upserted and fetched do not match, upserted=5, fetched=4 > expected:<[00B0y01, 00B0y02, 00B0y03, > 00B0y04, 00B0y05]> but was:<[00B0y01, > 00B0y02, 00B0y03, 00B0y04]> > > > Subsequent manual test runs went well: > > [INFO] Running org.apache.phoenix.end2end.IndexToolForNonTxGlobalIndexIT > [WARNING] Tests run: 72, Failures: 0, Errors: 0, Skipped: 4, Time elapsed: > 1,010.964 s - in org.apache.phoenix.end2end.IndexToolForNonTxGlobalIndexIT > > [INFO] Running org.apache.phoenix.end2end.ViewTTLIT > [INFO] Tests run: 26, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: > 772.233 s - in org.apache.phoenix.end2end.ViewTTLIT > > > > On 2021/02/27 00:51:06, Geoffrey Jacoby wrote: > > +1 (binding) > > > > Check signatures and checksums: OK > > apache-rat:check for licenses : OK > > mvn clean install -DskipTests: OK > > mvn verify for new 2.4.1 support: OK after rerunning one crashed test > > > > Geoffrey > > > > > > On Fri, Feb 26, 2021 at 6:04 AM Istvan Toth wrote: > > > > > Please vote on this Apache phoenix release candidate, > > > phoenix-5.1.1RC0 > > > > > > The VOTE will remain open for at least 72 hours. > > > > > > [ ] +1 Release this package as Apache phoenix 5.1.1 > > > [ ] -1 Do not release this package because ... > > > > > > The tag to be voted on is 5.1.1RC0: > > > > > > https://github.com/apache/phoenix/tree/5.1.1RC0 > > > > > > The release files, including signatures, digests, as well as CHANGES.md > > > and RELEASENOTES.md included in this RC can be found at: > > > > > > https://dist.apache.org/repos/dist/dev/phoenix/phoenix-5.1.1RC0/ > > > > > > Maven artifacts are available in a staging repository at: > > > > > > https://repository.apache.org/#stagingRepositories > > > (orgapachephoenix-1215) > > > > > > Artifacts were signed with the 0x794433C7 key which can be found in: > > > > > > https://dist.apache.org/repos/dist/release/phoenix/KEYS > > > > > > To learn more about Apache phoenix, please see > > > > > > http://phoenix.apache.org/ > > > > > > Thanks, > > > Istvan > > > > > >
[jira] [Resolved] (PHOENIX-6402) Allow using local indexes with uncovered columns in the WHERE clause
[ https://issues.apache.org/jira/browse/PHOENIX-6402?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lars Hofhansl resolved PHOENIX-6402. Resolution: Fixed Merged into master and cherry-picked into 5.1 and 4.x [~kozdemir] thanks for the brain storming and review. > Allow using local indexes with uncovered columns in the WHERE clause > > > Key: PHOENIX-6402 > URL: https://issues.apache.org/jira/browse/PHOENIX-6402 > Project: Phoenix > Issue Type: Improvement >Reporter: Lars Hofhansl >Assignee: Lars Hofhansl >Priority: Blocker > Fix For: 5.1.1, 4.16.1, 5.2.0 > > Attachments: 6402-5.1-v4.txt, 6402-WIP-5.1-v2.txt, > 6402-WIP-5.1-v3.txt, 6402-WIP-5.1.txt > > > In PHOENIX-6400 I had to disable using local index when uncovered columns are > referenced in the WHERE clause. > There are two problems: > # The uncovered columns are represented as ProjectedColumnExpression and not > correctly added as filters by the WhereCompiler > # The scanner produced in RegionScannerFactory.getWrappedScanner does not > handle this correctly. > [~kozdemir] and I brainstormed this today. > What should happen is this: > * Do not add uncovered column expression as filters for local indexes (they > would not be evaluated at right time) > * Pass the extra filter expression via a scan attribute > * Do something similar to what we do with conditional expressions (see > PhoenixIndexBuilder.executeAtomicOp), where we assemble the complete tuple, > then run the filter expression over it. > This would probably require some surgery, so filing it here as an Improvement > in case someone signs up for it :) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (PHOENIX-6407) phoenixdb for Python silently ignores placeholders < placeholder arguments
[
https://issues.apache.org/jira/browse/PHOENIX-6407?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ben DeMott updated PHOENIX-6407:
Labels: phoenixdb (was: )
> phoenixdb for Python silently ignores placeholders < placeholder arguments
> --
>
> Key: PHOENIX-6407
> URL: https://issues.apache.org/jira/browse/PHOENIX-6407
> Project: Phoenix
> Issue Type: Bug
> Components: python
>Affects Versions: 5.1.0
>Reporter: Ben DeMott
>Priority: Minor
> Labels: phoenixdb
>
> The `phoenixdb` driver for Python does not alert the user to excess arguments
> that are not represented by placeholders.
> *Example 1*, fewer arguments than placeholders raise exception (works as
> expected)
>
> {code:java}
> cursor.execute("UPSERT INTO users VALUES (?, ?, ?)", (123, 'John Doe')) {code}
> {noformat}
> phoenixdb.errors.ProgrammingError: ('Number of columns upserting must match
> number of values. Numbers of columns: 3. Number of values: 4
> tableName=USERS', 1020, '42Y60', None){noformat}
> *Example 2,* additional arguments than placeholders is silently ignored
> {code:java}
> cursor.execute("UPSERT INTO users VALUES (?, ?)", (123, 'John Doe',
> 'admin')){code}
> The program should generate a similar error to the one above, that the
> columns need to match the replacements.
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (PHOENIX-6407) phoenixdb for Python silently ignores placeholders < placeholder arguments
[
https://issues.apache.org/jira/browse/PHOENIX-6407?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ben DeMott updated PHOENIX-6407:
Component/s: python
> phoenixdb for Python silently ignores placeholders < placeholder arguments
> --
>
> Key: PHOENIX-6407
> URL: https://issues.apache.org/jira/browse/PHOENIX-6407
> Project: Phoenix
> Issue Type: Bug
> Components: python
>Affects Versions: 5.1.0
>Reporter: Ben DeMott
>Priority: Minor
>
> The `phoenixdb` driver for Python does not alert the user to excess arguments
> that are not represented by placeholders.
> *Example 1*, fewer arguments than placeholders raise exception (works as
> expected)
>
> {code:java}
> cursor.execute("UPSERT INTO users VALUES (?, ?, ?)", (123, 'John Doe')) {code}
> {noformat}
> phoenixdb.errors.ProgrammingError: ('Number of columns upserting must match
> number of values. Numbers of columns: 3. Number of values: 4
> tableName=USERS', 1020, '42Y60', None){noformat}
> *Example 2,* additional arguments than placeholders is silently ignored
> {code:java}
> cursor.execute("UPSERT INTO users VALUES (?, ?)", (123, 'John Doe',
> 'admin')){code}
> The program should generate a similar error to the one above, that the
> columns need to match the replacements.
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
Topic suggestions for April Tech Talk
Hi All, This is a friendly reminder that our next tech talk meeting will be held at 9AM PST on April 01. If you like to present a topic for the next meeting, please let us know by March 18. For more information about our tech talks, and the slides and recording for the previous presentation, please visit https://phoenix.apache.org/tech_talks.html. I look forward to your suggestions for the next meeting. Thanks, Kadir
[jira] [Updated] (PHOENIX-6407) phoenixdb for Python silently ignores placeholders < placeholder arguments
[
https://issues.apache.org/jira/browse/PHOENIX-6407?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ben DeMott updated PHOENIX-6407:
Summary: phoenixdb for Python silently ignores placeholders < placeholder
arguments (was: phoenidb for Python silently ignores placeholders <
placeholder arguments)
> phoenixdb for Python silently ignores placeholders < placeholder arguments
> --
>
> Key: PHOENIX-6407
> URL: https://issues.apache.org/jira/browse/PHOENIX-6407
> Project: Phoenix
> Issue Type: Bug
>Affects Versions: 5.1.0
>Reporter: Ben DeMott
>Priority: Minor
>
> The `phoenixdb` driver for Python does not alert the user to excess arguments
> that are not represented by placeholders.
> *Example 1*, fewer arguments than placeholders raise exception (works as
> expected)
>
> {code:java}
> cursor.execute("UPSERT INTO users VALUES (?, ?, ?)", (123, 'John Doe')) {code}
> {noformat}
> phoenixdb.errors.ProgrammingError: ('Number of columns upserting must match
> number of values. Numbers of columns: 3. Number of values: 4
> tableName=USERS', 1020, '42Y60', None){noformat}
> *Example 2,* additional arguments than placeholders is silently ignored
> {code:java}
> cursor.execute("UPSERT INTO users VALUES (?, ?)", (123, 'John Doe',
> 'admin')){code}
> The program should generate a similar error to the one above, that the
> columns need to match the replacements.
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (PHOENIX-6407) phoenidb for Python silently ignores placeholders < placeholder arguments
[
https://issues.apache.org/jira/browse/PHOENIX-6407?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ben DeMott updated PHOENIX-6407:
Description:
The `phoenixdb` driver for Python does not alert the user to excess arguments
that are not represented by placeholders.
*Example 1*, fewer arguments than placeholders raise exception (works as
expected)
{code:java}
cursor.execute("UPSERT INTO users VALUES (?, ?, ?)", (123, 'John Doe')) {code}
{noformat}
phoenixdb.errors.ProgrammingError: ('Number of columns upserting must match
number of values. Numbers of columns: 3. Number of values: 4 tableName=USERS',
1020, '42Y60', None){noformat}
*Example 2,* additional arguments than placeholders is silently ignored
{code:java}
cursor.execute("UPSERT INTO users VALUES (?, ?)", (123, 'John Doe',
'admin')){code}
The program should generate a similar error to the one above, that the columns
need to match the replacements.
was:
The `phoenixdb` driver for Python does not alert the user to excess arguments
that are not represented by placeholders.
*Example 1*, fewer arguments than placeholders raise exception (works as
expected)
{code:java}
cursor.execute("UPSERT INTO users VALUES (?, ?, ?)", (123, 'John Doe')) {code}
{noformat}
phoenixdb.errors.ProgrammingError: ('Number of columns upserting must match
number of values. Numbers of columns: 3. Number of values: 4 tableName=USERS',
1020, '42Y60', None){noformat}
*Example 2,* additional arguments than placeholders is silently ignored
{code:java}
cursor.execute("UPSERT INTO users VALUES (?, ?)", (123, 'John Doe',
'admin')){code}
**The program should generate a similar error as to the one above that the
columns need to match the replacements.
> phoenidb for Python silently ignores placeholders < placeholder arguments
> -
>
> Key: PHOENIX-6407
> URL: https://issues.apache.org/jira/browse/PHOENIX-6407
> Project: Phoenix
> Issue Type: Bug
>Affects Versions: 5.1.0
>Reporter: Ben DeMott
>Priority: Minor
>
> The `phoenixdb` driver for Python does not alert the user to excess arguments
> that are not represented by placeholders.
> *Example 1*, fewer arguments than placeholders raise exception (works as
> expected)
>
> {code:java}
> cursor.execute("UPSERT INTO users VALUES (?, ?, ?)", (123, 'John Doe')) {code}
> {noformat}
> phoenixdb.errors.ProgrammingError: ('Number of columns upserting must match
> number of values. Numbers of columns: 3. Number of values: 4
> tableName=USERS', 1020, '42Y60', None){noformat}
> *Example 2,* additional arguments than placeholders is silently ignored
> {code:java}
> cursor.execute("UPSERT INTO users VALUES (?, ?)", (123, 'John Doe',
> 'admin')){code}
> The program should generate a similar error to the one above, that the
> columns need to match the replacements.
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (PHOENIX-6407) phoenidb for Python silently ignores placeholders < placeholder arguments
Ben DeMott created PHOENIX-6407:
---
Summary: phoenidb for Python silently ignores placeholders <
placeholder arguments
Key: PHOENIX-6407
URL: https://issues.apache.org/jira/browse/PHOENIX-6407
Project: Phoenix
Issue Type: Bug
Affects Versions: 5.1.0
Reporter: Ben DeMott
The `phoenixdb` driver for Python does not alert the user to excess arguments
that are not represented by placeholders.
*Example 1*, fewer arguments than placeholders raise exception (works as
expected)
{code:java}
cursor.execute("UPSERT INTO users VALUES (?, ?, ?)", (123, 'John Doe')) {code}
{noformat}
phoenixdb.errors.ProgrammingError: ('Number of columns upserting must match
number of values. Numbers of columns: 3. Number of values: 4 tableName=USERS',
1020, '42Y60', None){noformat}
*Example 2,* additional arguments than placeholders is silently ignored
{code:java}
cursor.execute("UPSERT INTO users VALUES (?, ?)", (123, 'John Doe',
'admin')){code}
**The program should generate a similar error as to the one above that the
columns need to match the replacements.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
