[jira] [Comment Edited] (OAK-8969) Ignore domain overwrite doesn't work well when presignedHttpDownloadURICacheMaxSize is set
[ https://issues.apache.org/jira/browse/OAK-8969?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17066396#comment-17066396 ] Matt Ryan edited comment on OAK-8969 at 3/25/20, 5:22 AM: -- Fixed in [r1875608|https://svn.apache.org/viewvc?view=revision=1875608]. Needs to be backported also to 1.22. Does it also need to backport to 1.26? was (Author: mattvryan): Fixed in [r1875608|https://svn.apache.org/viewvc?view=revision=1875608]. Needs to be backported also to 1.26 and 1.22. > Ignore domain overwrite doesn't work well when > presignedHttpDownloadURICacheMaxSize is set > -- > > Key: OAK-8969 > URL: https://issues.apache.org/jira/browse/OAK-8969 > Project: Jackrabbit Oak > Issue Type: Bug > Components: blob-cloud >Affects Versions: 1.26.0 >Reporter: Jun Zhang >Assignee: Matt Ryan >Priority: Major > Fix For: 1.22.3, 1.28.0 > > > Ignore domain overwrite doesn't work well when > presignedHttpDownloadURICacheMaxSize is set -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (OAK-8969) Ignore domain overwrite doesn't work well when presignedHttpDownloadURICacheMaxSize is set
[ https://issues.apache.org/jira/browse/OAK-8969?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Ryan updated OAK-8969: --- Fix Version/s: 1.28.0 1.22.3 > Ignore domain overwrite doesn't work well when > presignedHttpDownloadURICacheMaxSize is set > -- > > Key: OAK-8969 > URL: https://issues.apache.org/jira/browse/OAK-8969 > Project: Jackrabbit Oak > Issue Type: Bug > Components: blob-cloud >Affects Versions: 1.26.0 >Reporter: Jun Zhang >Assignee: Matt Ryan >Priority: Major > Fix For: 1.22.3, 1.28.0 > > > Ignore domain overwrite doesn't work well when > presignedHttpDownloadURICacheMaxSize is set -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (OAK-8969) Ignore domain overwrite doesn't work well when presignedHttpDownloadURICacheMaxSize is set
[ https://issues.apache.org/jira/browse/OAK-8969?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17066396#comment-17066396 ] Matt Ryan commented on OAK-8969: Fixed in [r1875608|https://svn.apache.org/viewvc?view=revision=1875608]. Needs to be backported also to 1.26 and 1.22. > Ignore domain overwrite doesn't work well when > presignedHttpDownloadURICacheMaxSize is set > -- > > Key: OAK-8969 > URL: https://issues.apache.org/jira/browse/OAK-8969 > Project: Jackrabbit Oak > Issue Type: Bug > Components: blob-cloud >Affects Versions: 1.26.0 >Reporter: Jun Zhang >Assignee: Matt Ryan >Priority: Major > > Ignore domain overwrite doesn't work well when > presignedHttpDownloadURICacheMaxSize is set -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (OAK-8969) Ignore domain overwrite doesn't work well when presignedHttpDownloadURICacheMaxSize is set
[ https://issues.apache.org/jira/browse/OAK-8969?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Ryan updated OAK-8969: --- Affects Version/s: 1.26.0 > Ignore domain overwrite doesn't work well when > presignedHttpDownloadURICacheMaxSize is set > -- > > Key: OAK-8969 > URL: https://issues.apache.org/jira/browse/OAK-8969 > Project: Jackrabbit Oak > Issue Type: Bug > Components: blob-cloud >Affects Versions: 1.26.0 >Reporter: Jun Zhang >Assignee: Matt Ryan >Priority: Major > > Ignore domain overwrite doesn't work well when > presignedHttpDownloadURICacheMaxSize is set -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (OAK-8969) Ignore domain overwrite doesn't work well when presignedHttpDownloadURICacheMaxSize is set
[ https://issues.apache.org/jira/browse/OAK-8969?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17066218#comment-17066218 ] Matt Ryan commented on OAK-8969: If caching is enabled then there is a chance that a URI previously generated without ignoring a domain override will be reused out of cache when another URI for the same blob ID is requested again. If the subsequent request wants to ignore the domain override then the wrong URI will then be pulled from the cache, if the URI hasn't expired yet, because the key for the cache is just the blob ID. A simple solution to this would be to compute the value of the download URI domain beforehand, and then use that along with the blob ID for the cache key. The domain value will be different if the domain override ignore flag is set than it would be if it is not set, so this would result in a cache miss and the correct URI being returned. > Ignore domain overwrite doesn't work well when > presignedHttpDownloadURICacheMaxSize is set > -- > > Key: OAK-8969 > URL: https://issues.apache.org/jira/browse/OAK-8969 > Project: Jackrabbit Oak > Issue Type: Bug > Components: blob-cloud >Reporter: Jun Zhang >Assignee: Matt Ryan >Priority: Major > > Ignore domain overwrite doesn't work well when > presignedHttpDownloadURICacheMaxSize is set -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (OAK-8969) Ignore domain overwrite doesn't work well when presignedHttpDownloadURICacheMaxSize is set
[ https://issues.apache.org/jira/browse/OAK-8969?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Ryan reassigned OAK-8969: -- Assignee: Matt Ryan > Ignore domain overwrite doesn't work well when > presignedHttpDownloadURICacheMaxSize is set > -- > > Key: OAK-8969 > URL: https://issues.apache.org/jira/browse/OAK-8969 > Project: Jackrabbit Oak > Issue Type: Bug > Components: blob-cloud >Reporter: Jun Zhang >Assignee: Matt Ryan >Priority: Major > > Ignore domain overwrite doesn't work well when > presignedHttpDownloadURICacheMaxSize is set -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (OAK-8969) Ignore domain overwrite doesn't work well when presignedHttpDownloadURICacheMaxSize is set
Jun Zhang created OAK-8969: -- Summary: Ignore domain overwrite doesn't work well when presignedHttpDownloadURICacheMaxSize is set Key: OAK-8969 URL: https://issues.apache.org/jira/browse/OAK-8969 Project: Jackrabbit Oak Issue Type: Bug Components: blob-cloud Reporter: Jun Zhang Ignore domain overwrite doesn't work well when presignedHttpDownloadURICacheMaxSize is set -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (OAK-8657) SimpleCredentialsSupport uses Guava API in exported API
[
https://issues.apache.org/jira/browse/OAK-8657?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17065920#comment-17065920
]
Julian Reschke commented on OAK-8657:
-
Proposed change: [^OAK-8657.diff]
> SimpleCredentialsSupport uses Guava API in exported API
> ---
>
> Key: OAK-8657
> URL: https://issues.apache.org/jira/browse/OAK-8657
> Project: Jackrabbit Oak
> Issue Type: Technical task
> Components: security-spi
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Blocker
> Fix For: 1.28.0
>
> Attachments: OAK-8657.diff
>
>
> {noformat}
> @Override
> @NotNull
> public ImmutableSet getCredentialClasses() {
> return ImmutableSet.of(SimpleCredentials.class);
> }
> {noformat}
> We should fix this to use a regular `Set` (as in the implemented interface).
> However, this would be an incompatible API change; we could do that in sync
> with OAK-7358.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (OAK-8657) SimpleCredentialsSupport uses Guava API in exported API
[
https://issues.apache.org/jira/browse/OAK-8657?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Reschke updated OAK-8657:
Attachment: OAK-8657.diff
> SimpleCredentialsSupport uses Guava API in exported API
> ---
>
> Key: OAK-8657
> URL: https://issues.apache.org/jira/browse/OAK-8657
> Project: Jackrabbit Oak
> Issue Type: Technical task
> Components: security-spi
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Blocker
> Fix For: 1.28.0
>
> Attachments: OAK-8657.diff
>
>
> {noformat}
> @Override
> @NotNull
> public ImmutableSet getCredentialClasses() {
> return ImmutableSet.of(SimpleCredentials.class);
> }
> {noformat}
> We should fix this to use a regular `Set` (as in the implemented interface).
> However, this would be an incompatible API change; we could do that in sync
> with OAK-7358.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (OAK-8657) SimpleCredentialsSupport uses Guava API in exported API
[
https://issues.apache.org/jira/browse/OAK-8657?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17065871#comment-17065871
]
Julian Reschke commented on OAK-8657:
-
FWIW, the changes for OAK-7358 proved to be harder to get accepted in the
downstream project than expected, so I (reluctantly) left his change out.
> SimpleCredentialsSupport uses Guava API in exported API
> ---
>
> Key: OAK-8657
> URL: https://issues.apache.org/jira/browse/OAK-8657
> Project: Jackrabbit Oak
> Issue Type: Technical task
> Components: security-spi
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Blocker
> Fix For: 1.28.0
>
>
> {noformat}
> @Override
> @NotNull
> public ImmutableSet getCredentialClasses() {
> return ImmutableSet.of(SimpleCredentials.class);
> }
> {noformat}
> We should fix this to use a regular `Set` (as in the implemented interface).
> However, this would be an incompatible API change; we could do that in sync
> with OAK-7358.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (OAK-8967) OR query with ORDER BY and query.setLimit don't work as expected
[ https://issues.apache.org/jira/browse/OAK-8967?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mohit Kataria updated OAK-8967: --- Description: A query with Or and having order by along with limit Don't reproduce results as per order mentioned. e.g. Let content be: "/UnionQueryTest1/node0", "/UnionQueryTest/node0", "/UnionQueryTest1/node0/node1", "/UnionQueryTest/node0/node1", "/UnionQueryTest1/node0/node1/node2", "/UnionQueryTest/node0/node1/node2", "/UnionQueryTest1/node0/node1/node2/node3", "/UnionQueryTest/node0/node1/node2/node3" each node having x = number in node name. SELECT idn1.* FROM [nt:base] as idn1 WHERE ISDESCENDANTNODE([/UnionQueryTest]) OR ISDESCENDANTNODE([/UnionQueryTest1]) ORDER BY idn1.[x] ASC result should be same as above mentioned where as current result come out to be /UnionQueryTest1/node0 /UnionQueryTest1/node0/node1 /UnionQueryTest1/node0/node1/node2 /UnionQueryTest1/node0/node1/node2/node3 /UnionQueryTest1/node0/node1/node2/node3/node4 /UnionQueryTest/node0 /UnionQueryTest/node0/node1 /UnionQueryTest/node0/node1/node2 was:A query with Or and having order by along with limit Don't reproduce results as per order mentioned. > OR query with ORDER BY and query.setLimit don't work as expected > - > > Key: OAK-8967 > URL: https://issues.apache.org/jira/browse/OAK-8967 > Project: Jackrabbit Oak > Issue Type: Bug >Reporter: Mohit Kataria >Assignee: Mohit Kataria >Priority: Major > > A query with Or and having order by along with limit Don't reproduce results > as per order mentioned. > e.g. > Let content be: > "/UnionQueryTest1/node0", > "/UnionQueryTest/node0", > "/UnionQueryTest1/node0/node1", > "/UnionQueryTest/node0/node1", > "/UnionQueryTest1/node0/node1/node2", > "/UnionQueryTest/node0/node1/node2", > "/UnionQueryTest1/node0/node1/node2/node3", > "/UnionQueryTest/node0/node1/node2/node3" > each node having x = number in node name. > SELECT idn1.* FROM [nt:base] as idn1 WHERE > ISDESCENDANTNODE([/UnionQueryTest]) OR ISDESCENDANTNODE([/UnionQueryTest1]) > ORDER BY idn1.[x] ASC > > result should be same as above mentioned where as current result come out to > be > /UnionQueryTest1/node0 > /UnionQueryTest1/node0/node1 > /UnionQueryTest1/node0/node1/node2 > /UnionQueryTest1/node0/node1/node2/node3 > /UnionQueryTest1/node0/node1/node2/node3/node4 > /UnionQueryTest/node0 > /UnionQueryTest/node0/node1 > /UnionQueryTest/node0/node1/node2 > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (OAK-8967) OR query with ORDER BY don't work as expected
[ https://issues.apache.org/jira/browse/OAK-8967?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mohit Kataria updated OAK-8967: --- Summary: OR query with ORDER BY don't work as expected (was: OR query with ORDER BY and query.setLimit don't work as expected) > OR query with ORDER BY don't work as expected > -- > > Key: OAK-8967 > URL: https://issues.apache.org/jira/browse/OAK-8967 > Project: Jackrabbit Oak > Issue Type: Bug >Reporter: Mohit Kataria >Assignee: Mohit Kataria >Priority: Major > > A query with Or and having order by along with limit Don't reproduce results > as per order mentioned. > e.g. > Let content be: > "/UnionQueryTest1/node0", > "/UnionQueryTest/node0", > "/UnionQueryTest1/node0/node1", > "/UnionQueryTest/node0/node1", > "/UnionQueryTest1/node0/node1/node2", > "/UnionQueryTest/node0/node1/node2", > "/UnionQueryTest1/node0/node1/node2/node3", > "/UnionQueryTest/node0/node1/node2/node3" > each node having x = number in node name. > SELECT idn1.* FROM [nt:base] as idn1 WHERE > ISDESCENDANTNODE([/UnionQueryTest]) OR ISDESCENDANTNODE([/UnionQueryTest1]) > ORDER BY idn1.[x] ASC > > result should be same as above mentioned where as current result come out to > be > /UnionQueryTest1/node0 > /UnionQueryTest1/node0/node1 > /UnionQueryTest1/node0/node1/node2 > /UnionQueryTest1/node0/node1/node2/node3 > /UnionQueryTest1/node0/node1/node2/node3/node4 > /UnionQueryTest/node0 > /UnionQueryTest/node0/node1 > /UnionQueryTest/node0/node1/node2 > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (OAK-8967) OR query with ORDER BY and query.setLimit don't work as expected
[ https://issues.apache.org/jira/browse/OAK-8967?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mohit Kataria updated OAK-8967: --- Summary: OR query with ORDER BY and query.setLimit don't work as expected (was: An OR query with ORDER BY and query.setLimit don't work as expected) > OR query with ORDER BY and query.setLimit don't work as expected > - > > Key: OAK-8967 > URL: https://issues.apache.org/jira/browse/OAK-8967 > Project: Jackrabbit Oak > Issue Type: Bug >Reporter: Mohit Kataria >Assignee: Mohit Kataria >Priority: Major > > A query with Or and having order by along with limit Don't reproduce results > as per order mentioned. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (OAK-8968) EOL Oak 1.0
[ https://issues.apache.org/jira/browse/OAK-8968?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke updated OAK-8968: Description: Users of 1.0 who can move to Java 8 should switch to the latest stable release (currently 1.26.0). Users of 1.0 who can move to Java 7 should switch to the latest stable release of 1.6. Users of 1.0 who still are on Java 6 can switch to the latest release of 1.2 (with the caveat that that will be EOL'd in a few months as well). What it'll mean in actual actions: - links will be removed from the download page - news will be posted on the homepage - [announce] will be sent to jr-user, jr-dev, oak-dev - branch and tags WILL stay there See also http://jackrabbit.apache.org/oak/docs/roadmap.html was: Users of 1.0 who can move to Java 8 should switch to the latest stable release (currently 1.26.0). Users of 1.0 who can move to Java 7 should switch to the latest stable release of 1.6. Users of 1.0 who still are on Java 6 can switch to the latest release of 1.2 (with the caveat that that will be EOL'd in a few months as well). What it'll mean in actual actions: links will be removed from the download page news will be posted on the homepage [announce] will be sent to jr-user, jr-dev, oak-dev branch and tags WILL stay there See also http://jackrabbit.apache.org/oak/docs/roadmap.html > EOL Oak 1.0 > --- > > Key: OAK-8968 > URL: https://issues.apache.org/jira/browse/OAK-8968 > Project: Jackrabbit Oak > Issue Type: Task >Reporter: Julian Reschke >Priority: Major > > Users of 1.0 who can move to Java 8 should switch to the latest stable > release (currently 1.26.0). > Users of 1.0 who can move to Java 7 should switch to the latest stable > release of 1.6. > Users of 1.0 who still are on Java 6 can switch to the latest release of 1.2 > (with the caveat that that will be EOL'd in a few months as well). > What it'll mean in actual actions: > - links will be removed from the download page > - news will be posted on the homepage > - [announce] will be sent to jr-user, jr-dev, oak-dev > - branch and tags WILL stay there > See also http://jackrabbit.apache.org/oak/docs/roadmap.html -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (OAK-8968) EOL Oak 1.0
Julian Reschke created OAK-8968: --- Summary: EOL Oak 1.0 Key: OAK-8968 URL: https://issues.apache.org/jira/browse/OAK-8968 Project: Jackrabbit Oak Issue Type: Task Reporter: Julian Reschke Users of 1.0 who can move to Java 8 should switch to the latest stable release (currently 1.26.0). Users of 1.0 who can move to Java 7 should switch to the latest stable release of 1.6. Users of 1.0 who still are on Java 6 can switch to the latest release of 1.2 (with the caveat that that will be EOL'd in a few months as well). What it'll mean in actual actions: links will be removed from the download page news will be posted on the homepage [announce] will be sent to jr-user, jr-dev, oak-dev branch and tags WILL stay there See also http://jackrabbit.apache.org/oak/docs/roadmap.html -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (OAK-8918) RDBBlobStore: warn when legacy (SQLServer) default collation is active
[
https://issues.apache.org/jira/browse/OAK-8918?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17065750#comment-17065750
]
Solomon Rutzky commented on OAK-8918:
-
{quote}Feel free to open a separate ticket.
{quote}
[~reschke], Done: OAK-8966
> RDBBlobStore: warn when legacy (SQLServer) default collation is active
> --
>
> Key: OAK-8918
> URL: https://issues.apache.org/jira/browse/OAK-8918
> Project: Jackrabbit Oak
> Issue Type: Technical task
> Components: rdbmk
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Minor
> Labels: candidate_oak_1_8
> Fix For: 1.26.0, 1.10.9, 1.22.2
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (OAK-8926) add RDBBlobStore performance test
[ https://issues.apache.org/jira/browse/OAK-8926?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17065365#comment-17065365 ] Julian Reschke commented on OAK-8926: - The code just uses a datasource. The tests use the Tomcat JDBC pool datasource config. > add RDBBlobStore performance test > - > > Key: OAK-8926 > URL: https://issues.apache.org/jira/browse/OAK-8926 > Project: Jackrabbit Oak > Issue Type: Technical task > Components: rdbmk >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Minor > Labels: candidate_oak_1_22 > Fix For: 1.26.0 > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (OAK-8926) add RDBBlobStore performance test
[ https://issues.apache.org/jira/browse/OAK-8926?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17065360#comment-17065360 ] Solomon Rutzky commented on OAK-8926: - Well, it was certainly worth a try, so thanks for testing that. One other question: is JDBC configured to use connection pooling? I checked the documentation but it wasn't clear as to whether or not connection pooling was enabled by default. If it's not being used, then it certainly needs to be enabled. > add RDBBlobStore performance test > - > > Key: OAK-8926 > URL: https://issues.apache.org/jira/browse/OAK-8926 > Project: Jackrabbit Oak > Issue Type: Technical task > Components: rdbmk >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Minor > Labels: candidate_oak_1_22 > Fix For: 1.26.0 > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (OAK-8966) RDBBlobStore: warn when ID columns are using legacy "SQL Server collation"
[
https://issues.apache.org/jira/browse/OAK-8966?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Solomon Rutzky updated OAK-8966:
Description:
This is primarily a fix for OAK-8918, which was intended to warn users of a
configuration (when using Microsoft SQL Server) that can lead to degraded
performance. Unfortunately, the code committed for that issue does not actually
check for this configuration directly, and hence can produce false positives
and negatives. This can be especially confusing to users to receive the warning
when it is coincidentally true, make the recommended changes, but then continue
to receive the warning message.
The issue is that the changes made in OAK-8918 check the default collation of
the database, yet that particular collation is only a factor when the tables –
{{DATASTORE_DATA}} and {{DATASTORE_META}} – are created (because the
{{COLLATE}} clause is not specified in the {{CREATE TABLE}} statements, but
that's being fixed via OAK-8963). Once the tables exist, then the default
collation of the database is no longer a factor since it's the collation of the
{{ID}} columns that affects performance. Thus, the check performed in OAK-8918
can be incorrect in two scenarios:
# No warning message is produced if the database is using a non-"{{SQL_}}"
collation yet the ID columns are set to a "{{SQL_}}" collation (which _should_
produce the warning message).
# A warning message is produced if the database is using a "{{SQL_}}"
collation yet the ID columns are _not_ set to a "{{SQL_}}" collation (which
should _not_ produce the warning message). And this will be the case once users
make the recommended change.
This can be fixed by checking the collation of each ID column (instead of
checking the collation of the database):
{code:sql}
SELECT col.[collation_name]
FROM sys.columns col
WHERE col.[object_id] = OBJECT_ID(?)
ANDcol.[name] = N'ID';
{code}
where the "{{?}}" is set to "{{tableName}}". Just call it twice, once for each
table.
was:
This is primarily a fix for OAK-8918, which was intended to warn users of a
configuration (when using Microsoft SQL Server) that can lead to degraded
performance. Unfortunately, the code committed for that issue does not actually
check for this configuration directly, and hence can produce false positives.
This can be especially confusing to users to receive the warning when it is
coincidentally true, make the recommended changes, but then continue to receive
the warning message.
The issue is that the changes made in OAK-8918 check the default collation of
the database, yet that particular collation is only a factor when the tables –
{{DATASTORE_DATA}} and {{DATASTORE_META}} – are created (because the
{{COLLATE}} clause is not specified in the {{CREATE TABLE}} statements, but
that's being fixed via OAK-8963). Once the tables exist, then the default
collation of the database is no longer a factor since it's the collation of the
{{ID}} columns that affects performance. Thus, the check performed in OAK-8918
can be incorrect in two scenarios:
# No warning message is produced if the database is using a non-"{{SQL_}}"
collation yet the ID columns are set to a "{{SQL_}}" collation (which _should_
produce the warning message).
# A warning message is produced if the database is using a "{{SQL_}}"
collation yet the ID columns are _not_ set to a "{{SQL_}}" collation (which
should _not_ produce the warning message). And this will be the case once users
make the recommended change.
This can be fixed by checking the collation of each ID column (instead of
checking the collation of the database):
{code:sql}
SELECT col.[collation_name]
FROM sys.columns col
WHERE col.[object_id] = OBJECT_ID(?)
ANDcol.[name] = N'ID';
{code}
where the "{{?}}" is set to "{{tableName}}". Just call it twice, once for each
table.
> RDBBlobStore: warn when ID columns are using legacy "SQL Server collation"
> --
>
> Key: OAK-8966
> URL: https://issues.apache.org/jira/browse/OAK-8966
> Project: Jackrabbit Oak
> Issue Type: Technical task
> Components: rdbmk
>Reporter: Solomon Rutzky
>Assignee: Julian Reschke
>Priority: Minor
>
> This is primarily a fix for OAK-8918, which was intended to warn users of a
> configuration (when using Microsoft SQL Server) that can lead to degraded
> performance. Unfortunately, the code committed for that issue does not
> actually check for this configuration directly, and hence can produce false
> positives and negatives. This can be especially confusing to users to receive
> the warning when it is coincidentally true, make the recommended changes, but
> then continue to receive the warning message.
>
> The issue is that the changes
[jira] [Updated] (OAK-8966) RDBBlobStore: warn when ID columns are using legacy "SQL Server collation"
[
https://issues.apache.org/jira/browse/OAK-8966?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Solomon Rutzky updated OAK-8966:
Description:
This is primarily a fix for OAK-8918, which was intended to warn users of a
configuration (when using Microsoft SQL Server) that can lead to degraded
performance. Unfortunately, the code committed for that issue does not actually
check for this configuration directly, and hence can produce false positives.
This can be especially confusing to users to receive the warning when it is
coincidentally true, make the recommended changes, but then continue to receive
the warning message.
The issue is that the changes made in OAK-8918 check the default collation of
the database, yet that particular collation is only a factor when the tables –
{{DATASTORE_DATA}} and {{DATASTORE_META}} – are created (because the
{{COLLATE}} clause is not specified in the {{CREATE TABLE}} statements, but
that's being fixed via OAK-8963). Once the tables exist, then the default
collation of the database is no longer a factor since it's the collation of the
{{ID}} columns that affects performance. Thus, the check performed in OAK-8918
can be incorrect in two scenarios:
# No warning message is produced if the database is using a non-"{{SQL_}}"
collation yet the ID columns are set to a "{{SQL_}}" collation (which _should_
produce the warning message).
# A warning message is produced if the database is using a "{{SQL_}}"
collation yet the ID columns are _not_ set to a "{{SQL_}}" collation (which
should _not_ produce the warning message). And this will be the case once users
make the recommended change.
This can be fixed by checking the collation of each ID column (instead of
checking the collation of the database):
{code:sql}
SELECT col.[collation_name]
FROM sys.columns col
WHERE col.[object_id] = OBJECT_ID(?)
ANDcol.[name] = N'ID';
{code}
where the "{{?}}" is set to "{{tableName}}". Just call it twice, once for each
table.
> RDBBlobStore: warn when ID columns are using legacy "SQL Server collation"
> --
>
> Key: OAK-8966
> URL: https://issues.apache.org/jira/browse/OAK-8966
> Project: Jackrabbit Oak
> Issue Type: Technical task
> Components: rdbmk
>Reporter: Solomon Rutzky
>Assignee: Julian Reschke
>Priority: Minor
>
> This is primarily a fix for OAK-8918, which was intended to warn users of a
> configuration (when using Microsoft SQL Server) that can lead to degraded
> performance. Unfortunately, the code committed for that issue does not
> actually check for this configuration directly, and hence can produce false
> positives. This can be especially confusing to users to receive the warning
> when it is coincidentally true, make the recommended changes, but then
> continue to receive the warning message.
>
> The issue is that the changes made in OAK-8918 check the default collation of
> the database, yet that particular collation is only a factor when the tables
> – {{DATASTORE_DATA}} and {{DATASTORE_META}} – are created (because the
> {{COLLATE}} clause is not specified in the {{CREATE TABLE}} statements, but
> that's being fixed via OAK-8963). Once the tables exist, then the default
> collation of the database is no longer a factor since it's the collation of
> the {{ID}} columns that affects performance. Thus, the check performed in
> OAK-8918 can be incorrect in two scenarios:
> # No warning message is produced if the database is using a non-"{{SQL_}}"
> collation yet the ID columns are set to a "{{SQL_}}" collation (which
> _should_ produce the warning message).
> # A warning message is produced if the database is using a "{{SQL_}}"
> collation yet the ID columns are _not_ set to a "{{SQL_}}" collation (which
> should _not_ produce the warning message). And this will be the case once
> users make the recommended change.
>
> This can be fixed by checking the collation of each ID column (instead of
> checking the collation of the database):
>
> {code:sql}
> SELECT col.[collation_name]
> FROM sys.columns col
> WHERE col.[object_id] = OBJECT_ID(?)
> ANDcol.[name] = N'ID';
> {code}
>
> where the "{{?}}" is set to "{{tableName}}". Just call it twice, once for
> each table.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (OAK-8967) An OR query with ORDER BY and query.setLimit don't work as expected
[ https://issues.apache.org/jira/browse/OAK-8967?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mohit Kataria updated OAK-8967: --- Description: A query with Or and having order by along with limit Don't reproduce results as per order mentioned. > An OR query with ORDER BY and query.setLimit don't work as expected > > > Key: OAK-8967 > URL: https://issues.apache.org/jira/browse/OAK-8967 > Project: Jackrabbit Oak > Issue Type: Bug >Reporter: Mohit Kataria >Assignee: Mohit Kataria >Priority: Major > > A query with Or and having order by along with limit Don't reproduce results > as per order mentioned. -- This message was sent by Atlassian Jira (v8.3.4#803005)
