[jira] [Commented] (OAK-2644) Lift the 150 character limit on node names
[ https://issues.apache.org/jira/browse/OAK-2644?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16861076#comment-16861076 ] Marcel Reutegger commented on OAK-2644: --- bq. Are there any considerations to keep in mind when modifying these? You should not modify those at all, unless you are experimenting on a dev system. bq. Specifically to our use case, in rare instances we have nodes that goes beyond the default node name limit of 350 characters (500 characters is our max). Would it be an option to store the long name in a property on that node and use the property value instead of the node name where appropriate? > Lift the 150 character limit on node names > -- > > Key: OAK-2644 > URL: https://issues.apache.org/jira/browse/OAK-2644 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: mongomk, rdbmk >Affects Versions: 1.0 >Reporter: Felix Meschberger >Priority: Major > > Currently -- as of Oak 1.1.7 and 1.0.12 releases -- there is a limit on the > length of 150 characters for item names in Oak. > This limit seems to be based upon a limitation in the MongoDB MK > implementation because MongoDB has a limit of 1024 bytes (I think) for > indexable properties. > I think this limitation is highly unexpected and seems to be largeyl > undocumented. For previous users of Jackrabbit it should probably at least be > documented on the [Backwards > Compatibility|http://jackrabbit.apache.org/oak/docs/differences.html] page. > The main problem, though, I have with this limit is, that it is based on a > limitation of a particular MK implementation and hits through the full stack. > I would have rather expected such a persistence limitation to be fully hidden > and handled inside the MK implementation. > Granted this limitation does not seem to violate the JCR 2.1 specification > which clearly states in section 3.2.4 Naming Restrictions: > bq. This definition of JCR name represents the least restrictive set of > constraints permitted for the naming of items and other entities. A > repository may further restrict the names of entities to a subset of JCR > names and in most cases is encouraged to do so. > and > bq. A writable repository may enforce any implementation-specific constraint > by causing an exception to be thrown on an invalid JCR write method call. > Still I think it is a questionable limitation for a generic repository where > such names may be auto-generated and thus be quite long depending on the use > case. > I understand this may be hard to fix but would still be happy to be able to > have (virtually) unlimited name length again as it was the case in Jackrabbit > 2. > Thanks. > See also OAK-333 for a previous discussion. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (OAK-2644) Lift the 150 character limit on node names
[ https://issues.apache.org/jira/browse/OAK-2644?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16858349#comment-16858349 ] Søren Jensen commented on OAK-2644: --- I see that it is possible to modify _oak.nodeNameLimit_ and _oak.pathLong_ through system properties. Are there any considerations to keep in mind when modifying these? Specifically to our use case, in rare instances we have nodes that goes beyond the default node name limit of 350 characters (500 characters is our max). Could increasing _oak.nodeNameLimit_ affect performance of the system as a whole in any way? > Lift the 150 character limit on node names > -- > > Key: OAK-2644 > URL: https://issues.apache.org/jira/browse/OAK-2644 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: mongomk, rdbmk >Affects Versions: 1.0 >Reporter: Felix Meschberger >Assignee: Thomas Mueller >Priority: Major > > Currently -- as of Oak 1.1.7 and 1.0.12 releases -- there is a limit on the > length of 150 characters for item names in Oak. > This limit seems to be based upon a limitation in the MongoDB MK > implementation because MongoDB has a limit of 1024 bytes (I think) for > indexable properties. > I think this limitation is highly unexpected and seems to be largeyl > undocumented. For previous users of Jackrabbit it should probably at least be > documented on the [Backwards > Compatibility|http://jackrabbit.apache.org/oak/docs/differences.html] page. > The main problem, though, I have with this limit is, that it is based on a > limitation of a particular MK implementation and hits through the full stack. > I would have rather expected such a persistence limitation to be fully hidden > and handled inside the MK implementation. > Granted this limitation does not seem to violate the JCR 2.1 specification > which clearly states in section 3.2.4 Naming Restrictions: > bq. This definition of JCR name represents the least restrictive set of > constraints permitted for the naming of items and other entities. A > repository may further restrict the names of entities to a subset of JCR > names and in most cases is encouraged to do so. > and > bq. A writable repository may enforce any implementation-specific constraint > by causing an exception to be thrown on an invalid JCR write method call. > Still I think it is a questionable limitation for a generic repository where > such names may be auto-generated and thus be quite long depending on the use > case. > I understand this may be hard to fix but would still be happy to be able to > have (virtually) unlimited name length again as it was the case in Jackrabbit > 2. > Thanks. > See also OAK-333 for a previous discussion. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (OAK-2644) Lift the 150 character limit on node names
[ https://issues.apache.org/jira/browse/OAK-2644?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14366818#comment-14366818 ] Felix Meschberger commented on OAK-2644: bq. The problem is node names. The limit on property names is much higher Thanks for the clarification. And yes, roughly 15MB for a property name is probably sufficient ;-) > Lift the 150 character limit on node names > -- > > Key: OAK-2644 > URL: https://issues.apache.org/jira/browse/OAK-2644 > Project: Jackrabbit Oak > Issue Type: Wish > Components: mongomk, rdbmk >Affects Versions: 1.0.12, 1.1.7 >Reporter: Felix Meschberger > > Currently -- as of Oak 1.1.7 and 1.0.12 releases -- there is a limit on the > length of 150 characters for item names in Oak. > This limit seems to be based upon a limitation in the MongoDB MK > implementation because MongoDB has a limit of 1024 bytes (I think) for > indexable properties. > I think this limitation is highly unexpected and seems to be largeyl > undocumented. For previous users of Jackrabbit it should probably at least be > documented on the [Backwards > Compatibility|http://jackrabbit.apache.org/oak/docs/differences.html] page. > The main problem, though, I have with this limit is, that it is based on a > limitation of a particular MK implementation and hits through the full stack. > I would have rather expected such a persistence limitation to be fully hidden > and handled inside the MK implementation. > Granted this limitation does not seem to violate the JCR 2.1 specification > which clearly states in section 3.2.4 Naming Restrictions: > bq. This definition of JCR name represents the least restrictive set of > constraints permitted for the naming of items and other entities. A > repository may further restrict the names of entities to a subset of JCR > names and in most cases is encouraged to do so. > and > bq. A writable repository may enforce any implementation-specific constraint > by causing an exception to be thrown on an invalid JCR write method call. > Still I think it is a questionable limitation for a generic repository where > such names may be auto-generated and thus be quite long depending on the use > case. > I understand this may be hard to fix but would still be happy to be able to > have (virtually) unlimited name length again as it was the case in Jackrabbit > 2. > Thanks. > See also OAK-333 for a previous discussion. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
