[jira] [Commented] (CONNECTORS-886) Add support for Parent folder security
[ https://issues.apache.org/jira/browse/CONNECTORS-886?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13896304#comment-13896304 ] Karl Wright commented on CONNECTORS-886: Hi Abe-san, I hope you had a good weekend. I bet you are working now to revise the patch. Before you do, though, I think it is a good idea to explain what SMB (and by extension, Windows) supports in this area. The big question in my mind is whether the Windows model for security for a document \\share\x\y\z is either A or B below: A: share acls for share document acls for \\share\x\y\z folder acls for \\share\x folder acls for \\share\x\y or B: share acls for share document acls for \\share\x\y\z parent acls for \\share\x\y, which include all parent levels folded together If B, your original solution is the most correct. So this is important to know. Thanks, Karl Add support for Parent folder security -- Key: CONNECTORS-886 URL: https://issues.apache.org/jira/browse/CONNECTORS-886 Project: ManifoldCF Issue Type: Improvement Components: JCIFS connector, Solr-4.x-component Reporter: Shinichiro Abe Fix For: ManifoldCF 1.6 Attachments: CONNECTORS-886-forSolrPlugin.patch, CONNECTORS-886.patch Windows server checks the access permission of a share folder and the security permission of a file document when we access a file via network. As far as I look into that, Windows does not take subfolder's security permissions into account. There is a case that someone who is admin wants to configure 'Everyone' for 'share folders' and configure each access permissions for 'sub folders'. E.g. \\ShareFolder\Admin -- Admin folder for administrative user, \\ShareFolder\Sales -- Sales folder for sales user. The users put files in 'sub folders', then the permission of these files will be inherited from the permission of 'sub folders'. I'd like to support access permissions for 'sub folders' in jcifs/solr connector. In general, we expect file's permission to be inherited from parent folder. So I want to manage parent's security by providing new [allow|deny]_token fields. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Resolved] (CONNECTORS-880) Under the right conditions, job aborts do not update last checked time
[ https://issues.apache.org/jira/browse/CONNECTORS-880?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Wright resolved CONNECTORS-880. Resolution: Fixed Under the right conditions, job aborts do not update last checked time Key: CONNECTORS-880 URL: https://issues.apache.org/jira/browse/CONNECTORS-880 Project: ManifoldCF Issue Type: Bug Components: Framework crawler agent Affects Versions: ManifoldCF 1.4.1 Reporter: Karl Wright Assignee: Karl Wright Fix For: ManifoldCF 1.6 When a scheduled job is being considered to be started, MCF updates the last-check field ONLY if the job didn't start. It relies on the job's completion to set the last-check field in the case where the job does start. But if the job aborts, in at least one case the last-check field is NOT updated. This leads to the job being run over and over again within the schedule window. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (CONNECTORS-886) Add support for Parent folder security
[ https://issues.apache.org/jira/browse/CONNECTORS-886?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Wright updated CONNECTORS-886: --- Assignee: Karl Wright Add support for Parent folder security -- Key: CONNECTORS-886 URL: https://issues.apache.org/jira/browse/CONNECTORS-886 Project: ManifoldCF Issue Type: Improvement Components: JCIFS connector, Solr-4.x-component Reporter: Shinichiro Abe Assignee: Karl Wright Fix For: ManifoldCF 1.6 Attachments: CONNECTORS-886-forSolrPlugin.patch, CONNECTORS-886.patch Windows server checks the access permission of a share folder and the security permission of a file document when we access a file via network. As far as I look into that, Windows does not take subfolder's security permissions into account. There is a case that someone who is admin wants to configure 'Everyone' for 'share folders' and configure each access permissions for 'sub folders'. E.g. \\ShareFolder\Admin -- Admin folder for administrative user, \\ShareFolder\Sales -- Sales folder for sales user. The users put files in 'sub folders', then the permission of these files will be inherited from the permission of 'sub folders'. I'd like to support access permissions for 'sub folders' in jcifs/solr connector. In general, we expect file's permission to be inherited from parent folder. So I want to manage parent's security by providing new [allow|deny]_token fields. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (CONNECTORS-886) Add support for Parent folder security
[ https://issues.apache.org/jira/browse/CONNECTORS-886?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Wright updated CONNECTORS-886: --- Assignee: Shinichiro Abe (was: Karl Wright) Add support for Parent folder security -- Key: CONNECTORS-886 URL: https://issues.apache.org/jira/browse/CONNECTORS-886 Project: ManifoldCF Issue Type: Improvement Components: JCIFS connector, Solr-4.x-component Reporter: Shinichiro Abe Assignee: Shinichiro Abe Fix For: ManifoldCF 1.6 Attachments: CONNECTORS-886-forSolrPlugin.patch, CONNECTORS-886.patch Windows server checks the access permission of a share folder and the security permission of a file document when we access a file via network. As far as I look into that, Windows does not take subfolder's security permissions into account. There is a case that someone who is admin wants to configure 'Everyone' for 'share folders' and configure each access permissions for 'sub folders'. E.g. \\ShareFolder\Admin -- Admin folder for administrative user, \\ShareFolder\Sales -- Sales folder for sales user. The users put files in 'sub folders', then the permission of these files will be inherited from the permission of 'sub folders'. I'd like to support access permissions for 'sub folders' in jcifs/solr connector. In general, we expect file's permission to be inherited from parent folder. So I want to manage parent's security by providing new [allow|deny]_token fields. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (CONNECTORS-886) Add support for Parent folder security
[ https://issues.apache.org/jira/browse/CONNECTORS-886?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Wright updated CONNECTORS-886: --- Component/s: Solr-3.x-component Framework agents process Affects Version/s: ManifoldCF 1.6 Add support for Parent folder security -- Key: CONNECTORS-886 URL: https://issues.apache.org/jira/browse/CONNECTORS-886 Project: ManifoldCF Issue Type: Improvement Components: Framework agents process, JCIFS connector, Solr-3.x-component, Solr-4.x-component Affects Versions: ManifoldCF 1.6 Reporter: Shinichiro Abe Assignee: Shinichiro Abe Fix For: ManifoldCF 1.6 Attachments: CONNECTORS-886-forSolrPlugin.patch, CONNECTORS-886.patch Windows server checks the access permission of a share folder and the security permission of a file document when we access a file via network. As far as I look into that, Windows does not take subfolder's security permissions into account. There is a case that someone who is admin wants to configure 'Everyone' for 'share folders' and configure each access permissions for 'sub folders'. E.g. \\ShareFolder\Admin -- Admin folder for administrative user, \\ShareFolder\Sales -- Sales folder for sales user. The users put files in 'sub folders', then the permission of these files will be inherited from the permission of 'sub folders'. I'd like to support access permissions for 'sub folders' in jcifs/solr connector. In general, we expect file's permission to be inherited from parent folder. So I want to manage parent's security by providing new [allow|deny]_token fields. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (CONNECTORS-886) Add support for Parent folder security
[ https://issues.apache.org/jira/browse/CONNECTORS-886?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Wright updated CONNECTORS-886: --- Component/s: ElasticSearch component Add support for Parent folder security -- Key: CONNECTORS-886 URL: https://issues.apache.org/jira/browse/CONNECTORS-886 Project: ManifoldCF Issue Type: Improvement Components: ElasticSearch component, Framework agents process, JCIFS connector, Solr-3.x-component, Solr-4.x-component Affects Versions: ManifoldCF 1.6 Reporter: Shinichiro Abe Assignee: Shinichiro Abe Fix For: ManifoldCF 1.6 Attachments: CONNECTORS-886-forSolrPlugin.patch, CONNECTORS-886.patch Windows server checks the access permission of a share folder and the security permission of a file document when we access a file via network. As far as I look into that, Windows does not take subfolder's security permissions into account. There is a case that someone who is admin wants to configure 'Everyone' for 'share folders' and configure each access permissions for 'sub folders'. E.g. \\ShareFolder\Admin -- Admin folder for administrative user, \\ShareFolder\Sales -- Sales folder for sales user. The users put files in 'sub folders', then the permission of these files will be inherited from the permission of 'sub folders'. I'd like to support access permissions for 'sub folders' in jcifs/solr connector. In general, we expect file's permission to be inherited from parent folder. So I want to manage parent's security by providing new [allow|deny]_token fields. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
Let's plan for a 1.5.1 release in not too much time
Hi all, ManifoldCF trunk already has a schema change vs. the 1.5 release, which means that people wanting minor fixes will have to apply patches to the 1.5 release themselves. So I think that it makes sense to consider releasing MCF 1.5.1 at some point in the not-too-distant future. The tickets I think we ought to include in a proposed 1.5.1 bug fix release so far are: CONNECTORS-884 CONNECTORS-882 CONNECTORS-877 CONNECTORS-876 CONNECTORS-875 There may, of course, be others -- but this would cover the ones currently known. For now, the idea would be to pull up fixes for these tickets to the release-1.5-branch, so at least they'd all be available together until we decide 1.5.1 is ready to ship. Thoughts? Karl
[jira] [Updated] (CONNECTORS-884) Solr connector: Successful index posts are not recorded in simple history
[ https://issues.apache.org/jira/browse/CONNECTORS-884?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Wright updated CONNECTORS-884: --- Fix Version/s: ManifoldCF 1.5.1 Solr connector: Successful index posts are not recorded in simple history - Key: CONNECTORS-884 URL: https://issues.apache.org/jira/browse/CONNECTORS-884 Project: ManifoldCF Issue Type: Bug Components: Lucene/SOLR connector Affects Versions: ManifoldCF 1.5 Reporter: Karl Wright Assignee: Karl Wright Fix For: ManifoldCF 1.5.1, ManifoldCF 1.6 Solr connector: Successful index posts are not recorded in simple history. Exceptions are, but not successful posts. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (CONNECTORS-882) Solr connector: Keep all metadata not working
[ https://issues.apache.org/jira/browse/CONNECTORS-882?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13896479#comment-13896479 ] Karl Wright commented on CONNECTORS-882: r1566610 (release 1.5 branch) Solr connector: Keep all metadata not working - Key: CONNECTORS-882 URL: https://issues.apache.org/jira/browse/CONNECTORS-882 Project: ManifoldCF Issue Type: Bug Components: Lucene/SOLR connector Affects Versions: ManifoldCF 1.5 Reporter: Karl Wright Assignee: Karl Wright Fix For: ManifoldCF 1.5.1, ManifoldCF 1.6 Attachments: CONNECTORS-882.patch The problem is the pack/unpack apparently don't work together properly, for some reason that isn't immediately apparent: In pack: Keep all metadata = false After unpack: Keep all metadata = true -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (CONNECTORS-882) Solr connector: Keep all metadata not working
[ https://issues.apache.org/jira/browse/CONNECTORS-882?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Wright updated CONNECTORS-882: --- Fix Version/s: ManifoldCF 1.5.1 Solr connector: Keep all metadata not working - Key: CONNECTORS-882 URL: https://issues.apache.org/jira/browse/CONNECTORS-882 Project: ManifoldCF Issue Type: Bug Components: Lucene/SOLR connector Affects Versions: ManifoldCF 1.5 Reporter: Karl Wright Assignee: Karl Wright Fix For: ManifoldCF 1.5.1, ManifoldCF 1.6 Attachments: CONNECTORS-882.patch The problem is the pack/unpack apparently don't work together properly, for some reason that isn't immediately apparent: In pack: Keep all metadata = false After unpack: Keep all metadata = true -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (CONNECTORS-884) Solr connector: Successful index posts are not recorded in simple history
[ https://issues.apache.org/jira/browse/CONNECTORS-884?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13896482#comment-13896482 ] Karl Wright commented on CONNECTORS-884: r1566615 (release 1.5 branch) Solr connector: Successful index posts are not recorded in simple history - Key: CONNECTORS-884 URL: https://issues.apache.org/jira/browse/CONNECTORS-884 Project: ManifoldCF Issue Type: Bug Components: Lucene/SOLR connector Affects Versions: ManifoldCF 1.5 Reporter: Karl Wright Assignee: Karl Wright Fix For: ManifoldCF 1.5.1, ManifoldCF 1.6 Solr connector: Successful index posts are not recorded in simple history. Exceptions are, but not successful posts. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (CONNECTORS-875) LiveLink connector: LAPI exceptions not always caught
[
https://issues.apache.org/jira/browse/CONNECTORS-875?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Wright updated CONNECTORS-875:
---
Fix Version/s: ManifoldCF 1.5.1
LiveLink connector: LAPI exceptions not always caught
-
Key: CONNECTORS-875
URL: https://issues.apache.org/jira/browse/CONNECTORS-875
Project: ManifoldCF
Issue Type: Bug
Components: LiveLink connector
Affects Versions: ManifoldCF 1.4.1
Reporter: Karl Wright
Assignee: Karl Wright
Fix For: ManifoldCF 1.5.1, ManifoldCF 1.6
Attachments: CONNECTORS-875.patch, refactor.patch
LAPI has the ability to communicate via HTTP with the LiveLink server.
Unfortunately, if something goes wrong on the server side, LAPI does not
behave well and throws all sorts of runtime exceptions. For example:
{code}
2014-01-30 17:44:17,773 [Worker thread '43'] FATAL
org.apache.manifoldcf.crawlerthreads- Error tossed: For input string:
h2500
java.lang.NumberFormatException: For input string: h2500
at
java.lang.NumberFormatException.forInputString(NumberFormatException.java:65)
at java.lang.Integer.parseInt(Integer.java:492)
at java.lang.Integer.init(Integer.java:677)
at com.opentext.api.LLConnect.readResponseHeaders(Unknown Source)
at com.opentext.api.LLConnect.executeHTTP(Unknown Source)
at com.opentext.api.LLConnect.execute(Unknown Source)
at com.opentext.api.LAPI_DOCUMENTS.GetObjectInfo(Unknown Source)
at
org.apache.manifoldcf.crawler.connectors.livelink.LivelinkConnector$GetObjectInfoThread.run(LivelinkConnector.java:6370)
{code}
Other examples include ArrayIndexOutOfBoundsException, etc.
It would be good to catch these and deal with them in a saner way than
killing off and restarting the worker thread.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (CONNECTORS-875) LiveLink connector: LAPI exceptions not always caught
[
https://issues.apache.org/jira/browse/CONNECTORS-875?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13896484#comment-13896484
]
Karl Wright commented on CONNECTORS-875:
r1566616 (release 1.5 branch)
LiveLink connector: LAPI exceptions not always caught
-
Key: CONNECTORS-875
URL: https://issues.apache.org/jira/browse/CONNECTORS-875
Project: ManifoldCF
Issue Type: Bug
Components: LiveLink connector
Affects Versions: ManifoldCF 1.4.1
Reporter: Karl Wright
Assignee: Karl Wright
Fix For: ManifoldCF 1.5.1, ManifoldCF 1.6
Attachments: CONNECTORS-875.patch, refactor.patch
LAPI has the ability to communicate via HTTP with the LiveLink server.
Unfortunately, if something goes wrong on the server side, LAPI does not
behave well and throws all sorts of runtime exceptions. For example:
{code}
2014-01-30 17:44:17,773 [Worker thread '43'] FATAL
org.apache.manifoldcf.crawlerthreads- Error tossed: For input string:
h2500
java.lang.NumberFormatException: For input string: h2500
at
java.lang.NumberFormatException.forInputString(NumberFormatException.java:65)
at java.lang.Integer.parseInt(Integer.java:492)
at java.lang.Integer.init(Integer.java:677)
at com.opentext.api.LLConnect.readResponseHeaders(Unknown Source)
at com.opentext.api.LLConnect.executeHTTP(Unknown Source)
at com.opentext.api.LLConnect.execute(Unknown Source)
at com.opentext.api.LAPI_DOCUMENTS.GetObjectInfo(Unknown Source)
at
org.apache.manifoldcf.crawler.connectors.livelink.LivelinkConnector$GetObjectInfoThread.run(LivelinkConnector.java:6370)
{code}
Other examples include ArrayIndexOutOfBoundsException, etc.
It would be good to catch these and deal with them in a saner way than
killing off and restarting the worker thread.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Updated] (CONNECTORS-876) Solr connector: when HTTP error code 500 is returned, the error message should contain some identifying information
[
https://issues.apache.org/jira/browse/CONNECTORS-876?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Wright updated CONNECTORS-876:
---
Fix Version/s: ManifoldCF 1.5.1
Solr connector: when HTTP error code 500 is returned, the error message
should contain some identifying information
---
Key: CONNECTORS-876
URL: https://issues.apache.org/jira/browse/CONNECTORS-876
Project: ManifoldCF
Issue Type: Bug
Components: Lucene/SOLR connector
Affects Versions: ManifoldCF 1.4.1
Reporter: Karl Wright
Assignee: Karl Wright
Fix For: ManifoldCF 1.5.1, ManifoldCF 1.6
Attachments: CONNECTORS-876.patch
When Solr throws an error, it would be great if the connector could include
enough diagnostic information in the exception and/or log so that people
could chase down the originating document in question. Right now all you get
is:
{code}
Exception tossed: Repeated service interruptions - failure processing
document: Server at https://llsrchsolqa1:8443/solr/Lisa returned non ok
status:500, message:Internal Server Error
org.apache.manifoldcf.core.interfaces.ManifoldCFException: Repeated service
interruptions - failure processing document: Server at
https://llsrchsolqa1:8443/solr/Lisa returned non ok status:500,
message:Internal Server Error
at
org.apache.manifoldcf.crawler.system.WorkerThread.run(WorkerThread.java:586)
Caused by: org.apache.solr.common.SolrException: Server at
https://llsrchsolqa1:8443/solr/Lisa returned non ok status:500,
message:Internal Server Error
at
org.apache.manifoldcf.agents.output.solr.ModifiedHttpSolrServer.request(ModifiedHttpSolrServer.java:311)
at
org.apache.solr.client.solrj.impl.HttpSolrServer.request(HttpSolrServer.java:180)
at
org.apache.solr.client.solrj.request.AbstractUpdateRequest.process(AbstractUpdateRequest.java:117)
at
org.apache.manifoldcf.agents.output.solr.HttpPoster$IngestThread.run(HttpPoster.java:919)
{code}
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Updated] (CONNECTORS-877) Solr connector: Missing i18n key SolrConnector.StatusPathMustStartWithACharacter
[ https://issues.apache.org/jira/browse/CONNECTORS-877?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Wright updated CONNECTORS-877: --- Fix Version/s: ManifoldCF 1.5.1 Solr connector: Missing i18n key SolrConnector.StatusPathMustStartWithACharacter Key: CONNECTORS-877 URL: https://issues.apache.org/jira/browse/CONNECTORS-877 Project: ManifoldCF Issue Type: Bug Components: Lucene/SOLR connector Affects Versions: ManifoldCF 1.5 Reporter: Karl Wright Assignee: Karl Wright Fix For: ManifoldCF 1.5.1, ManifoldCF 1.6 SolrConnector.StatusPathMustStartWithACharacter seems to be missing from the translation properties. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (CONNECTORS-877) Solr connector: Missing i18n key SolrConnector.StatusPathMustStartWithACharacter
[ https://issues.apache.org/jira/browse/CONNECTORS-877?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13896487#comment-13896487 ] Karl Wright commented on CONNECTORS-877: r1566618 (release 1.5 branch) Solr connector: Missing i18n key SolrConnector.StatusPathMustStartWithACharacter Key: CONNECTORS-877 URL: https://issues.apache.org/jira/browse/CONNECTORS-877 Project: ManifoldCF Issue Type: Bug Components: Lucene/SOLR connector Affects Versions: ManifoldCF 1.5 Reporter: Karl Wright Assignee: Karl Wright Fix For: ManifoldCF 1.5.1, ManifoldCF 1.6 SolrConnector.StatusPathMustStartWithACharacter seems to be missing from the translation properties. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
Re: [Solr Output Connector] Keep All Metadata Flag broken
Hi Alessandro,
In prep for an eventual 1.5.1 release, I pulled up this ticket (and others)
to the release-1.5-branch. So if you need this feature, you can get it by
checking out branches/release-1.5-branch and building.
Thanks,
Karl
On Wed, Feb 5, 2014 at 3:19 PM, Karl Wright daddy...@gmail.com wrote:
The code was right, but there was two lines of spurious unpack code in
there left over from some previous connector modification. See
CONNECTORS-882. I've attached a patch to the ticket; if there's another RC
of 1.5 I'll pull it up there as well. But I don't think we should spin
another RC for this problem alone.
Karl
On Wed, Feb 5, 2014 at 2:00 PM, Karl Wright daddy...@gmail.com wrote:
Sorry, that should have been: unpacking:
// extract keep all metadata Flag
boolean keepAllMetadata = true;
if (index outputDescription.length())
{
keepAllMetadata = (outputDescription.charAt(index++) == '+');
}
... and here's the packing:
boolean keepAllMetadata = true;
while (i spec.getChildCount()) {
SpecificationNode sn = spec.getChild(i++);
if(sn.getType().equals(
SolrConfig.NODE_KEEPMETADATA)) {
String value = sn.getAttributeValue(SolrConfig.ATTRIBUTE_VALUE);
keepAllMetadata = Boolean.parseBoolean(value);
}
...
}
...
// Keep all metadata flag
if (keepAllMetadata)
sb.append('+');
else
sb.append('-');
On Wed, Feb 5, 2014 at 1:58 PM, Karl Wright daddy...@gmail.com wrote:
Hi Alessandro,
The implementation was changed from the patch, for two reasons: first,
because of backwards compatibility requirements, and second because the
packing/unpacking was taking place at the wrong time. Here's the unpacking:
boolean keepAllMetadata = true;
while (i spec.getChildCount()) {
SpecificationNode sn = spec.getChild(i++);
if(sn.getType().equals(SolrConfig.NODE_KEEPMETADATA)) {
String value = sn.getAttributeValue(SolrConfig.ATTRIBUTE_VALUE);
keepAllMetadata = Boolean.parseBoolean(value);
}
...
}
// extract keep all metadata Flag
boolean keepAllMetadata = true;
if (index outputDescription.length())
{
keepAllMetadata = (outputDescription.charAt(index++) == '+');
}
... and here's the packing:
// Keep all metadata flag
if (keepAllMetadata)
sb.append('+');
else
sb.append('-');
This looks correct to me. What does your debugging session show?
Karl
On Wed, Feb 5, 2014 at 12:44 PM, Alessandro Benedetti
benedetti.ale...@gmail.com wrote:
Hi guys,
the flag keep All Metadata is broken.
After a debug session
In this line, whatever you click in the ui you get keepAllMetadata=true
:
Class :
SolrConnector
Code :
// extract keep all metadata Flag
boolean keepAllMetadata = true;
if (index outputDescription.length())
{
keepAllMetadata = (outputDescription.charAt(index++) == '+');
}
It seems the implementation has been a little bit changed from our
original
patch...
Am I wrong ? Any hint ?
Cheers
--
--
Benedetti Alessandro
Visiting card : http://about.me/alessandro_benedetti
Tyger, tyger burning bright
In the forests of the night,
What immortal hand or eye
Could frame thy fearful symmetry?
William Blake - Songs of Experience -1794 England
Re: Let's plan for a 1.5.1 release in not too much time
Hi Karl, Please pull up CONNECTORS-870, it's super trivial though. Shinichiro 2014-02-10 21:47 GMT+09:00 Karl Wright daddy...@gmail.com: Hi all, ManifoldCF trunk already has a schema change vs. the 1.5 release, which means that people wanting minor fixes will have to apply patches to the 1.5 release themselves. So I think that it makes sense to consider releasing MCF 1.5.1 at some point in the not-too-distant future. The tickets I think we ought to include in a proposed 1.5.1 bug fix release so far are: CONNECTORS-884 CONNECTORS-882 CONNECTORS-877 CONNECTORS-876 CONNECTORS-875 There may, of course, be others -- but this would cover the ones currently known. For now, the idea would be to pull up fixes for these tickets to the release-1.5-branch, so at least they'd all be available together until we decide 1.5.1 is ready to ship. Thoughts? Karl -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Shinichiro Abe 阿部 慎一朗
[jira] [Commented] (CONNECTORS-886) Add support for Parent folder security
[ https://issues.apache.org/jira/browse/CONNECTORS-886?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13896585#comment-13896585 ] Shinichiro Abe commented on CONNECTORS-886: --- I agree your design. I'll provide 'mcf.auth.directoryCount' param. If null, then the filtering by share, document. If 0, then the filtering by share, direcory_0, document. If 1, then the filtering by share, direcory_0, direcory_1, document. The answer of your question is B, not A. The permissions of the document is inherited from the one of y folder, the permissions of y folder is inherited from the one of x folder. I'll write the version2 patch this/next week. Add support for Parent folder security -- Key: CONNECTORS-886 URL: https://issues.apache.org/jira/browse/CONNECTORS-886 Project: ManifoldCF Issue Type: Improvement Components: ElasticSearch component, Framework agents process, JCIFS connector, Solr-3.x-component, Solr-4.x-component Affects Versions: ManifoldCF 1.6 Reporter: Shinichiro Abe Assignee: Shinichiro Abe Fix For: ManifoldCF 1.6 Attachments: CONNECTORS-886-forSolrPlugin.patch, CONNECTORS-886.patch Windows server checks the access permission of a share folder and the security permission of a file document when we access a file via network. As far as I look into that, Windows does not take subfolder's security permissions into account. There is a case that someone who is admin wants to configure 'Everyone' for 'share folders' and configure each access permissions for 'sub folders'. E.g. \\ShareFolder\Admin -- Admin folder for administrative user, \\ShareFolder\Sales -- Sales folder for sales user. The users put files in 'sub folders', then the permission of these files will be inherited from the permission of 'sub folders'. I'd like to support access permissions for 'sub folders' in jcifs/solr connector. In general, we expect file's permission to be inherited from parent folder. So I want to manage parent's security by providing new [allow|deny]_token fields. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (CONNECTORS-870) Avoid line break for login.jsp description when locale is Japanese
[ https://issues.apache.org/jira/browse/CONNECTORS-870?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Wright updated CONNECTORS-870: --- Fix Version/s: ManifoldCF 1.5.1 Avoid line break for login.jsp description when locale is Japanese -- Key: CONNECTORS-870 URL: https://issues.apache.org/jira/browse/CONNECTORS-870 Project: ManifoldCF Issue Type: Bug Components: Framework core Affects Versions: ManifoldCF 1.4.1 Reporter: Shinichiro Abe Assignee: Shinichiro Abe Priority: Trivial Fix For: ManifoldCF 1.5.1, ManifoldCF 1.6 Attachments: CONNECTORS-870.patch, Login-When-Local-is-Japanese.png At login page, UserID and Password label are shown as line break when locale is Japanese. See attached png file. So I would like to add nobr tag for right display. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
Re: Let's plan for a 1.5.1 release in not too much time
Done. Karl On Mon, Feb 10, 2014 at 9:07 AM, Shinichiro Abe shinichiro.ab...@gmail.comwrote: Hi Karl, Please pull up CONNECTORS-870, it's super trivial though. Shinichiro 2014-02-10 21:47 GMT+09:00 Karl Wright daddy...@gmail.com: Hi all, ManifoldCF trunk already has a schema change vs. the 1.5 release, which means that people wanting minor fixes will have to apply patches to the 1.5 release themselves. So I think that it makes sense to consider releasing MCF 1.5.1 at some point in the not-too-distant future. The tickets I think we ought to include in a proposed 1.5.1 bug fix release so far are: CONNECTORS-884 CONNECTORS-882 CONNECTORS-877 CONNECTORS-876 CONNECTORS-875 There may, of course, be others -- but this would cover the ones currently known. For now, the idea would be to pull up fixes for these tickets to the release-1.5-branch, so at least they'd all be available together until we decide 1.5.1 is ready to ship. Thoughts? Karl -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Shinichiro Abe 阿部 慎一朗
[jira] [Commented] (CONNECTORS-870) Avoid line break for login.jsp description when locale is Japanese
[ https://issues.apache.org/jira/browse/CONNECTORS-870?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13896597#comment-13896597 ] Karl Wright commented on CONNECTORS-870: r1566637 (release-1.5-branch) Avoid line break for login.jsp description when locale is Japanese -- Key: CONNECTORS-870 URL: https://issues.apache.org/jira/browse/CONNECTORS-870 Project: ManifoldCF Issue Type: Bug Components: Framework core Affects Versions: ManifoldCF 1.4.1 Reporter: Shinichiro Abe Assignee: Shinichiro Abe Priority: Trivial Fix For: ManifoldCF 1.5.1, ManifoldCF 1.6 Attachments: CONNECTORS-870.patch, Login-When-Local-is-Japanese.png At login page, UserID and Password label are shown as line break when locale is Japanese. See attached png file. So I would like to add nobr tag for right display. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Created] (CONNECTORS-887) Database schema not updated properly
Florian Schmedding created CONNECTORS-887: - Summary: Database schema not updated properly Key: CONNECTORS-887 URL: https://issues.apache.org/jira/browse/CONNECTORS-887 Project: ManifoldCF Issue Type: Bug Components: Framework core Affects Versions: ManifoldCF 1.6 Environment: MySQL database Reporter: Florian Schmedding Priority: Minor When running Manifold 1.6 the first time with an database schema from Manifold 1.3 the schema is not updated properly. The SQL-command ALTER TABLE authconnections MODIFY groupname VARCHAR(32) NOT NULL REFERENCES authgroups(groupname) ON DELETE RESTRICT fails. It should instead add the column: ALTER TABLE authconnections ADD groupname VARCHAR(32) NOT NULL REFERENCES authgroups(groupname) ON DELETE RESTRICT The next startup after executing the corrected SQL-statement succeeds. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (CONNECTORS-887) Database schema not updated properly
[
https://issues.apache.org/jira/browse/CONNECTORS-887?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13896759#comment-13896759
]
Karl Wright commented on CONNECTORS-887:
Actually, the upgrade first adds the column, then modifies it after creating
the corresponding authority group:
{code}
cd = (ColumnDescription)existing.get(groupNameField);
if (cd == null)
{
Map addMap = new HashMap();
addMap.put(groupNameField,new
ColumnDescription(VARCHAR(32),false,true,
authMgr.getTableName(),authMgr.getGroupNameColumn(),false));
performAlter(addMap,null,null,null);
boolean revert = true;
try
{
ArrayList params = new ArrayList();
IResultSet set = performQuery(SELECT
+nameField+,+descriptionField+ FROM +getTableName(),null,null,null);
for (int i = 0 ; i set.getRowCount() ; i++)
{
IResultRow row = set.getRow(i);
String authName = (String)row.getValue(nameField);
String authDescription = (String)row.getValue(descriptionField);
// Attempt to create a matching auth group. This will fail if
the group
// already exists
IAuthorityGroup grp = authMgr.create();
grp.setName(authName);
grp.setDescription(authDescription);
try
{
authMgr.save(grp);
}
catch (ManifoldCFException e)
{
if (e.getErrorCode() == ManifoldCFException.INTERRUPTED)
throw e;
// Fall through; the row exists already
}
MapString,String map = new HashMapString,String();
map.put(groupNameField,authName);
params.clear();
String query = buildConjunctionClause(params,new
ClauseDescription[]{
new UnitaryClause(nameField,authName)});
performUpdate(map, WHERE +query,params,null);
}
Map modifyMap = new HashMap();
modifyMap.put(groupNameField,new
ColumnDescription(VARCHAR(32),false,false,
authMgr.getTableName(),authMgr.getGroupNameColumn(),false));
performAlter(null,modifyMap,null,null);
revert = false;
}
finally
{
if (revert)
{
// Upgrade failed; back out our changes
ListString deleteList = new ArrayListString();
deleteList.add(groupNameField);
performAlter(null,null,deleteList,null);
}
}
}
{code}
I tried this on a PostgreSQL instance to be sure it worked; it did. Is there
anything unique about your setup that would prevent the above code from working
in your case?
Database schema not updated properly
Key: CONNECTORS-887
URL: https://issues.apache.org/jira/browse/CONNECTORS-887
Project: ManifoldCF
Issue Type: Bug
Components: Framework core
Affects Versions: ManifoldCF 1.6
Environment: MySQL database
Reporter: Florian Schmedding
Priority: Minor
Labels: database, easyfix
When running Manifold 1.6 the first time with an database schema from
Manifold 1.3 the schema is not updated properly. The SQL-command
ALTER TABLE authconnections MODIFY groupname VARCHAR(32) NOT NULL REFERENCES
authgroups(groupname) ON DELETE RESTRICT
fails. It should instead add the column:
ALTER TABLE authconnections ADD groupname VARCHAR(32) NOT NULL REFERENCES
authgroups(groupname) ON DELETE RESTRICT
The next startup after executing the corrected SQL-statement succeeds.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Updated] (CONNECTORS-887) Database schema not updated properly
[ https://issues.apache.org/jira/browse/CONNECTORS-887?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Wright updated CONNECTORS-887: --- Affects Version/s: (was: ManifoldCF 1.6) ManifoldCF 1.5 Fix Version/s: ManifoldCF 1.6 ManifoldCF 1.5.1 Database schema not updated properly Key: CONNECTORS-887 URL: https://issues.apache.org/jira/browse/CONNECTORS-887 Project: ManifoldCF Issue Type: Bug Components: Framework core Affects Versions: ManifoldCF 1.5 Environment: MySQL database Reporter: Florian Schmedding Assignee: Karl Wright Priority: Minor Labels: database, easyfix Fix For: ManifoldCF 1.5.1, ManifoldCF 1.6 When running Manifold 1.6 the first time with an database schema from Manifold 1.3 the schema is not updated properly. The SQL-command ALTER TABLE authconnections MODIFY groupname VARCHAR(32) NOT NULL REFERENCES authgroups(groupname) ON DELETE RESTRICT fails. It should instead add the column: ALTER TABLE authconnections ADD groupname VARCHAR(32) NOT NULL REFERENCES authgroups(groupname) ON DELETE RESTRICT The next startup after executing the corrected SQL-statement succeeds. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Assigned] (CONNECTORS-887) Database schema not updated properly
[ https://issues.apache.org/jira/browse/CONNECTORS-887?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Wright reassigned CONNECTORS-887: -- Assignee: Karl Wright Database schema not updated properly Key: CONNECTORS-887 URL: https://issues.apache.org/jira/browse/CONNECTORS-887 Project: ManifoldCF Issue Type: Bug Components: Framework core Affects Versions: ManifoldCF 1.5 Environment: MySQL database Reporter: Florian Schmedding Assignee: Karl Wright Priority: Minor Labels: database, easyfix Fix For: ManifoldCF 1.5.1, ManifoldCF 1.6 When running Manifold 1.6 the first time with an database schema from Manifold 1.3 the schema is not updated properly. The SQL-command ALTER TABLE authconnections MODIFY groupname VARCHAR(32) NOT NULL REFERENCES authgroups(groupname) ON DELETE RESTRICT fails. It should instead add the column: ALTER TABLE authconnections ADD groupname VARCHAR(32) NOT NULL REFERENCES authgroups(groupname) ON DELETE RESTRICT The next startup after executing the corrected SQL-statement succeeds. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (CONNECTORS-887) Database schema not updated properly
[ https://issues.apache.org/jira/browse/CONNECTORS-887?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13896765#comment-13896765 ] Karl Wright commented on CONNECTORS-887: Ah, I just noticed that your database is MySQL. I did not notice that earlier. If you can provide the actual stack trace of the upgrade failure, that would be great. If not, I will need to look at this later tonight. Database schema not updated properly Key: CONNECTORS-887 URL: https://issues.apache.org/jira/browse/CONNECTORS-887 Project: ManifoldCF Issue Type: Bug Components: Framework core Affects Versions: ManifoldCF 1.5 Environment: MySQL database Reporter: Florian Schmedding Assignee: Karl Wright Priority: Minor Labels: database, easyfix Fix For: ManifoldCF 1.5.1, ManifoldCF 1.6 When running Manifold 1.6 the first time with an database schema from Manifold 1.3 the schema is not updated properly. The SQL-command ALTER TABLE authconnections MODIFY groupname VARCHAR(32) NOT NULL REFERENCES authgroups(groupname) ON DELETE RESTRICT fails. It should instead add the column: ALTER TABLE authconnections ADD groupname VARCHAR(32) NOT NULL REFERENCES authgroups(groupname) ON DELETE RESTRICT The next startup after executing the corrected SQL-statement succeeds. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
Re: [Solr Output Connector] Keep All Metadata Flag broken
Hi Karl, in the last Trunk I downloaded few days ago, the feature was
there, corrected :)
So thank you !
2014-02-10 13:56 GMT+00:00 Karl Wright daddy...@gmail.com:
Hi Alessandro,
In prep for an eventual 1.5.1 release, I pulled up this ticket (and others)
to the release-1.5-branch. So if you need this feature, you can get it by
checking out branches/release-1.5-branch and building.
Thanks,
Karl
On Wed, Feb 5, 2014 at 3:19 PM, Karl Wright daddy...@gmail.com wrote:
The code was right, but there was two lines of spurious unpack code in
there left over from some previous connector modification. See
CONNECTORS-882. I've attached a patch to the ticket; if there's another
RC
of 1.5 I'll pull it up there as well. But I don't think we should spin
another RC for this problem alone.
Karl
On Wed, Feb 5, 2014 at 2:00 PM, Karl Wright daddy...@gmail.com wrote:
Sorry, that should have been: unpacking:
// extract keep all metadata Flag
boolean keepAllMetadata = true;
if (index outputDescription.length())
{
keepAllMetadata = (outputDescription.charAt(index++) == '+');
}
... and here's the packing:
boolean keepAllMetadata = true;
while (i spec.getChildCount()) {
SpecificationNode sn = spec.getChild(i++);
if(sn.getType().equals(
SolrConfig.NODE_KEEPMETADATA)) {
String value = sn.getAttributeValue(SolrConfig.ATTRIBUTE_VALUE);
keepAllMetadata = Boolean.parseBoolean(value);
}
...
}
...
// Keep all metadata flag
if (keepAllMetadata)
sb.append('+');
else
sb.append('-');
On Wed, Feb 5, 2014 at 1:58 PM, Karl Wright daddy...@gmail.com wrote:
Hi Alessandro,
The implementation was changed from the patch, for two reasons: first,
because of backwards compatibility requirements, and second because the
packing/unpacking was taking place at the wrong time. Here's the
unpacking:
boolean keepAllMetadata = true;
while (i spec.getChildCount()) {
SpecificationNode sn = spec.getChild(i++);
if(sn.getType().equals(SolrConfig.NODE_KEEPMETADATA)) {
String value =
sn.getAttributeValue(SolrConfig.ATTRIBUTE_VALUE);
keepAllMetadata = Boolean.parseBoolean(value);
}
...
}
// extract keep all metadata Flag
boolean keepAllMetadata = true;
if (index outputDescription.length())
{
keepAllMetadata = (outputDescription.charAt(index++) == '+');
}
... and here's the packing:
// Keep all metadata flag
if (keepAllMetadata)
sb.append('+');
else
sb.append('-');
This looks correct to me. What does your debugging session show?
Karl
On Wed, Feb 5, 2014 at 12:44 PM, Alessandro Benedetti
benedetti.ale...@gmail.com wrote:
Hi guys,
the flag keep All Metadata is broken.
After a debug session
In this line, whatever you click in the ui you get
keepAllMetadata=true
:
Class :
SolrConnector
Code :
// extract keep all metadata Flag
boolean keepAllMetadata = true;
if (index outputDescription.length())
{
keepAllMetadata = (outputDescription.charAt(index++) == '+');
}
It seems the implementation has been a little bit changed from our
original
patch...
Am I wrong ? Any hint ?
Cheers
--
--
Benedetti Alessandro
Visiting card : http://about.me/alessandro_benedetti
Tyger, tyger burning bright
In the forests of the night,
What immortal hand or eye
Could frame thy fearful symmetry?
William Blake - Songs of Experience -1794 England
--
--
Benedetti Alessandro
Visiting card : http://about.me/alessandro_benedetti
Tyger, tyger burning bright
In the forests of the night,
What immortal hand or eye
Could frame thy fearful symmetry?
William Blake - Songs of Experience -1794 England
[jira] [Commented] (CONNECTORS-880) Under the right conditions, job aborts do not update last checked time
[ https://issues.apache.org/jira/browse/CONNECTORS-880?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13896778#comment-13896778 ] Florian Schmedding commented on CONNECTORS-880: --- I installed mcf-combined-service.war version 1.6 on a Tomcat server. However, the test job is not working correctly. I've used an existing database from Manifold 1.3 with one existing output connection, one existing repository connection and one existing job. On the job status page there were no buttons to control the job, its status is End notification. Therefore I copied the job. Then there were buttons to start the new job, but it got only errors from the output connection when ingesting documents. After aborting the job, it got stuck with the status End notification and does not leave it. Should I better create new connections and jobs or are there other problems in version 1.6? Under the right conditions, job aborts do not update last checked time Key: CONNECTORS-880 URL: https://issues.apache.org/jira/browse/CONNECTORS-880 Project: ManifoldCF Issue Type: Bug Components: Framework crawler agent Affects Versions: ManifoldCF 1.4.1 Reporter: Karl Wright Assignee: Karl Wright Fix For: ManifoldCF 1.6 When a scheduled job is being considered to be started, MCF updates the last-check field ONLY if the job didn't start. It relies on the job's completion to set the last-check field in the case where the job does start. But if the job aborts, in at least one case the last-check field is NOT updated. This leads to the job being run over and over again within the schedule window. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (CONNECTORS-880) Under the right conditions, job aborts do not update last checked time
[ https://issues.apache.org/jira/browse/CONNECTORS-880?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13896788#comment-13896788 ] Karl Wright commented on CONNECTORS-880: Hi Florian, There are no other known problems in 1.6, but I have been working on the job state transitions. Specifically, the various kinds of ServiceInterruption from output connectors are now honored. So if you are using an output connector that is responding to a request with a ServiceInterruption, then unless that connector is sending the right variety of ServiceInterruption it is conceivable that it could retry indefinitely, or at least for much longer than you would like. Could you be more specific about which output connector you are using? Under the right conditions, job aborts do not update last checked time Key: CONNECTORS-880 URL: https://issues.apache.org/jira/browse/CONNECTORS-880 Project: ManifoldCF Issue Type: Bug Components: Framework crawler agent Affects Versions: ManifoldCF 1.4.1 Reporter: Karl Wright Assignee: Karl Wright Fix For: ManifoldCF 1.6 When a scheduled job is being considered to be started, MCF updates the last-check field ONLY if the job didn't start. It relies on the job's completion to set the last-check field in the case where the job does start. But if the job aborts, in at least one case the last-check field is NOT updated. This leads to the job being run over and over again within the schedule window. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Comment Edited] (CONNECTORS-880) Under the right conditions, job aborts do not update last checked time
[ https://issues.apache.org/jira/browse/CONNECTORS-880?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13896788#comment-13896788 ] Karl Wright edited comment on CONNECTORS-880 at 2/10/14 5:47 PM: - Hi Florian, There are no other known problems in 1.6, but I have been working on the job state transitions. Specifically, the various kinds of ServiceInterruption from output connectors are now honored. So if you are using an output connector that is responding to a request with a ServiceInterruption, then unless that connector is sending the right variety of ServiceInterruption it is conceivable that it could retry indefinitely, or at least for much longer than you would like. Could you be more specific about which output connector you are using? Also, if this is what is happening, you should definitely be seeing warnings in the manifoldcf log printed whenever the notification is retried. was (Author: kwri...@metacarta.com): Hi Florian, There are no other known problems in 1.6, but I have been working on the job state transitions. Specifically, the various kinds of ServiceInterruption from output connectors are now honored. So if you are using an output connector that is responding to a request with a ServiceInterruption, then unless that connector is sending the right variety of ServiceInterruption it is conceivable that it could retry indefinitely, or at least for much longer than you would like. Could you be more specific about which output connector you are using? Under the right conditions, job aborts do not update last checked time Key: CONNECTORS-880 URL: https://issues.apache.org/jira/browse/CONNECTORS-880 Project: ManifoldCF Issue Type: Bug Components: Framework crawler agent Affects Versions: ManifoldCF 1.4.1 Reporter: Karl Wright Assignee: Karl Wright Fix For: ManifoldCF 1.6 When a scheduled job is being considered to be started, MCF updates the last-check field ONLY if the job didn't start. It relies on the job's completion to set the last-check field in the case where the job does start. But if the job aborts, in at least one case the last-check field is NOT updated. This leads to the job being run over and over again within the schedule window. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (CONNECTORS-887) Database schema not updated properly
[
https://issues.apache.org/jira/browse/CONNECTORS-887?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13897039#comment-13897039
]
Karl Wright commented on CONNECTORS-887:
Was able to reproduce.
{code}
org.apache.manifoldcf.core.interfaces.ManifoldCFException: Database exception:
SQLException doing query (42000): You have an error in your SQL syntax; check
the manual that corresponds to your MySQL server version for the right syntax
to use near 'REFERENCES authgroups(groupname) ON DELETE RESTRICT' at line 1
at
org.apache.manifoldcf.core.database.Database$ExecuteQueryThread.finishUp(Database.java:702)
at
org.apache.manifoldcf.core.database.Database.executeViaThread(Database.java:728)
at
org.apache.manifoldcf.core.database.Database.executeUncachedQuery(Database.java:762)
at
org.apache.manifoldcf.core.database.Database$QueryCacheExecutor.create(Database.java:1435)
at
org.apache.manifoldcf.core.cachemanager.CacheManager.findObjectsAndExecute(CacheManager.java:144)
at
org.apache.manifoldcf.core.database.Database.executeQuery(Database.java:191)
at
org.apache.manifoldcf.core.database.DBInterfaceMySQL.performModification(DBInterfaceMySQL.java:691)
at
org.apache.manifoldcf.core.database.DBInterfaceMySQL.performAlter(DBInterfaceMySQL.java:423)
at
org.apache.manifoldcf.core.database.BaseTable.performAlter(BaseTable.java:118)
at
org.apache.manifoldcf.authorities.authority.AuthorityConnectionManager.install(AuthorityConnectionManager.java:169)
at
org.apache.manifoldcf.authorities.system.ManifoldCF.installSystemTables(ManifoldCF.java:125)
at
org.apache.manifoldcf.crawler.system.ManifoldCF.installSystemTables(ManifoldCF.java:532)
at
org.apache.manifoldcf.crawler.system.CrawlerAgent.install(CrawlerAgent.java:115)
at
org.apache.manifoldcf.agents.agentmanager.AgentManager.registerAgent(AgentManager.java:146)
at
org.apache.manifoldcf.crawler.system.ManifoldCF.registerThisAgent(ManifoldCF.java:136)
at
org.apache.manifoldcf.jettyrunner.ManifoldCFJettyRunner.main(ManifoldCFJettyRunner.java:210)
Caused by: com.mysql.jdbc.exceptions.jdbc4.MySQLSyntaxErrorException: You have
an error in your SQL syntax; check the manual that corresponds to your MySQL
server version for the right syntax to use near 'REFERENCES
authgroups(groupname) ON DELETE RESTRICT' at line 1
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)
at
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:525)
at com.mysql.jdbc.Util.handleNewInstance(Util.java:411)
at com.mysql.jdbc.Util.getInstance(Util.java:386)
at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:1052)
at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:3609)
at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:3541)
at com.mysql.jdbc.MysqlIO.sendCommand(MysqlIO.java:2002)
at com.mysql.jdbc.MysqlIO.sqlQueryDirect(MysqlIO.java:2163)
at com.mysql.jdbc.ConnectionImpl.execSQL(ConnectionImpl.java:2618)
at com.mysql.jdbc.ConnectionImpl.execSQL(ConnectionImpl.java:2568)
at com.mysql.jdbc.StatementImpl.execute(StatementImpl.java:842)
at com.mysql.jdbc.StatementImpl.execute(StatementImpl.java:681)
at
org.apache.manifoldcf.core.database.Database.execute(Database.java:854)
at
org.apache.manifoldcf.core.database.Database$ExecuteQueryThread.run(Database.java:683)
{code}
Database schema not updated properly
Key: CONNECTORS-887
URL: https://issues.apache.org/jira/browse/CONNECTORS-887
Project: ManifoldCF
Issue Type: Bug
Components: Framework core
Affects Versions: ManifoldCF 1.5
Environment: MySQL database
Reporter: Florian Schmedding
Assignee: Karl Wright
Priority: Minor
Labels: database, easyfix
Fix For: ManifoldCF 1.5.1, ManifoldCF 1.6
When running Manifold 1.6 the first time with an database schema from
Manifold 1.3 the schema is not updated properly. The SQL-command
ALTER TABLE authconnections MODIFY groupname VARCHAR(32) NOT NULL REFERENCES
authgroups(groupname) ON DELETE RESTRICT
fails. It should instead add the column:
ALTER TABLE authconnections ADD groupname VARCHAR(32) NOT NULL REFERENCES
authgroups(groupname) ON DELETE RESTRICT
The next startup after executing the corrected SQL-statement succeeds.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (CONNECTORS-887) Database schema not updated properly
[ https://issues.apache.org/jira/browse/CONNECTORS-887?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13897071#comment-13897071 ] Karl Wright commented on CONNECTORS-887: r1566761 (trunk) Database schema not updated properly Key: CONNECTORS-887 URL: https://issues.apache.org/jira/browse/CONNECTORS-887 Project: ManifoldCF Issue Type: Bug Components: Framework core Affects Versions: ManifoldCF 1.5 Environment: MySQL database Reporter: Florian Schmedding Assignee: Karl Wright Priority: Minor Labels: database, easyfix Fix For: ManifoldCF 1.5.1, ManifoldCF 1.6 When running Manifold 1.6 the first time with an database schema from Manifold 1.3 the schema is not updated properly. The SQL-command ALTER TABLE authconnections MODIFY groupname VARCHAR(32) NOT NULL REFERENCES authgroups(groupname) ON DELETE RESTRICT fails. It should instead add the column: ALTER TABLE authconnections ADD groupname VARCHAR(32) NOT NULL REFERENCES authgroups(groupname) ON DELETE RESTRICT The next startup after executing the corrected SQL-statement succeeds. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (CONNECTORS-887) Database schema not updated properly
[ https://issues.apache.org/jira/browse/CONNECTORS-887?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13897076#comment-13897076 ] Karl Wright commented on CONNECTORS-887: r1566762 (release-1.5-branch) Database schema not updated properly Key: CONNECTORS-887 URL: https://issues.apache.org/jira/browse/CONNECTORS-887 Project: ManifoldCF Issue Type: Bug Components: Framework core Affects Versions: ManifoldCF 1.5 Environment: MySQL database Reporter: Florian Schmedding Assignee: Karl Wright Priority: Minor Labels: database, easyfix Fix For: ManifoldCF 1.5.1, ManifoldCF 1.6 When running Manifold 1.6 the first time with an database schema from Manifold 1.3 the schema is not updated properly. The SQL-command ALTER TABLE authconnections MODIFY groupname VARCHAR(32) NOT NULL REFERENCES authgroups(groupname) ON DELETE RESTRICT fails. It should instead add the column: ALTER TABLE authconnections ADD groupname VARCHAR(32) NOT NULL REFERENCES authgroups(groupname) ON DELETE RESTRICT The next startup after executing the corrected SQL-statement succeeds. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Resolved] (CONNECTORS-887) Database schema not updated properly
[ https://issues.apache.org/jira/browse/CONNECTORS-887?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Wright resolved CONNECTORS-887. Resolution: Fixed Database schema not updated properly Key: CONNECTORS-887 URL: https://issues.apache.org/jira/browse/CONNECTORS-887 Project: ManifoldCF Issue Type: Bug Components: Framework core Affects Versions: ManifoldCF 1.5 Environment: MySQL database Reporter: Florian Schmedding Assignee: Karl Wright Priority: Minor Labels: database, easyfix Fix For: ManifoldCF 1.5.1, ManifoldCF 1.6 When running Manifold 1.6 the first time with an database schema from Manifold 1.3 the schema is not updated properly. The SQL-command ALTER TABLE authconnections MODIFY groupname VARCHAR(32) NOT NULL REFERENCES authgroups(groupname) ON DELETE RESTRICT fails. It should instead add the column: ALTER TABLE authconnections ADD groupname VARCHAR(32) NOT NULL REFERENCES authgroups(groupname) ON DELETE RESTRICT The next startup after executing the corrected SQL-statement succeeds. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
