You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@couchdb.apache.org by "Volker Mische (JIRA)" <ji...@apache.org> on 2011/01/03 12:16:45 UTC
[jira] Created: (COUCHDB-1006) Ability to replace substrings in
rewriter
Ability to replace substrings in rewriter
-----------------------------------------
Key: COUCHDB-1006
URL: https://issues.apache.org/jira/browse/COUCHDB-1006
Project: CouchDB
Issue Type: Improvement
Components: Database Core
Reporter: Volker Mische
Priority: Minor
The current rewriter is bound to the parts of a path. Therefore I propose and additional "replace" property to be able to rewrite URLs beyond that limitation. One example would be subpages in a wiki, where each subpage corresponds to one document in the database. Here's an example:
Desired URL:
http://example.com/wiki/apache-projects/couchdb/info
URL without rewriting:
http://example.com/wiki/apache-projects%2fcouchd%2f/info
Another use case is when you have to deal with attachments. For example if you want to build a TMS tilecache [1] bases on CouchDB. My URL would look like this (where "tile" is the attachement):
http://example.com/tilecache/3-5-2/tile
But I'd need an URL like
http://example.com/tilecache/tiles/3/5/2.png
(resp. http://example.com/tilecache/_design/tilecache/_rewrite/tiles/6/9/9.png)
My modification to the rewriter allows you to replace substrings with other ones. Here's the rewriter rule for this example:
{
"from" : "/tiles/<x>/<y>/<z>.png",
"to" : "..\\/..\\/:x/:y/:z/tile",
"replace": {
"old": "/",
"new": "-",
"limit": -1
}
}
It replaces all occurences of "/" with "-" on the "to"-path. Two slashes ("\\") escape a character, so it won't be replaced. The "limit" parameter specifies how many occurences should be replaced. It could be either positive, then it will just count how often a string was already replaced and stop at the limit. If "limit" is negative, it will count from the back. This is especially useful if you want to replace slashes and know how many slashes the attachment has, but not how many the document has.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (COUCHDB-1006) Ability to replace substrings in
rewriter
Posted by "Volker Mische (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/COUCHDB-1006?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Volker Mische updated COUCHDB-1006:
-----------------------------------
Attachment: rewrite-replace.patch
Allow replacement of substrings.
> Ability to replace substrings in rewriter
> -----------------------------------------
>
> Key: COUCHDB-1006
> URL: https://issues.apache.org/jira/browse/COUCHDB-1006
> Project: CouchDB
> Issue Type: Improvement
> Components: Database Core
> Reporter: Volker Mische
> Priority: Minor
> Attachments: rewrite-replace.patch
>
>
> The current rewriter is bound to the parts of a path. Therefore I propose and additional "replace" property to be able to rewrite URLs beyond that limitation. One example would be subpages in a wiki, where each subpage corresponds to one document in the database. Here's an example:
> Desired URL:
> http://example.com/wiki/apache-projects/couchdb/info
> URL without rewriting:
> http://example.com/wiki/apache-projects%2fcouchd%2f/info
> Another use case is when you have to deal with attachments. For example if you want to build a TMS tilecache [1] bases on CouchDB. My URL would look like this (where "tile" is the attachement):
> http://example.com/tilecache/3-5-2/tile
> But I'd need an URL like
> http://example.com/tilecache/tiles/3/5/2.png
> (resp. http://example.com/tilecache/_design/tilecache/_rewrite/tiles/6/9/9.png)
> My modification to the rewriter allows you to replace substrings with other ones. Here's the rewriter rule for this example:
> {
> "from" : "/tiles/<x>/<y>/<z>.png",
> "to" : "..\\/..\\/:x/:y/:z/tile",
> "replace": {
> "old": "/",
> "new": "-",
> "limit": -1
> }
> }
> It replaces all occurences of "/" with "-" on the "to"-path. Two slashes ("\\") escape a character, so it won't be replaced. The "limit" parameter specifies how many occurences should be replaced. It could be either positive, then it will just count how often a string was already replaced and stop at the limit. If "limit" is negative, it will count from the back. This is especially useful if you want to replace slashes and know how many slashes the attachment has, but not how many the document has.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (COUCHDB-1006) Ability to replace substrings in
rewriter
Posted by "Volker Mische (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/COUCHDB-1006?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Volker Mische updated COUCHDB-1006:
-----------------------------------
Description:
The current rewriter is bound to the parts of a path. Therefore I propose and additional "replace" property to be able to rewrite URLs beyond that limitation. One example would be subpages in a wiki, where each subpage corresponds to one document in the database. Here's an example:
Desired URL:
http://example.com/wiki/apache-projects/couchdb/info
URL without rewriting:
http://example.com/wiki/apache-projects%2fcouchd%2f/info
Another use case is when you have to deal with attachments. For example if you want to build a TMS tilecache [1] bases on CouchDB. My URL would look like this (where "tile" is the attachement):
http://example.com/tilecache/3-5-2/tile
But I'd need an URL like
http://example.com/tilecache/tiles/3/5/2.png
(resp. http://example.com/tilecache/_design/tilecache/_rewrite/tiles/6/9/9.png)
My modification to the rewriter allows you to replace substrings with other ones. Here's the rewriter rule for this example:
{
"from" : "/tiles/<x>/<y>/<z>.png",
"to" : "..\\/..\\/:x/:y/:z/tile",
"replace": {
"old": "/",
"new": "-",
"limit": -1
}
}
It replaces all occurences of "/" with "-" on the "to"-path. Two slashes ("\\") escape a character, so it won't be replaced. The "limit" parameter specifies how many occurences should be replaced. It could be either positive, then it will just count how often a string was already replaced and stop at the limit. If "limit" is negative, it will count from the back. This is especially useful if you want to replace slashes and know how many slashes the attachment has, but not how many the document has.
[1] http://wiki.osgeo.org/wiki/Tile_Map_Service_Specification
was:
The current rewriter is bound to the parts of a path. Therefore I propose and additional "replace" property to be able to rewrite URLs beyond that limitation. One example would be subpages in a wiki, where each subpage corresponds to one document in the database. Here's an example:
Desired URL:
http://example.com/wiki/apache-projects/couchdb/info
URL without rewriting:
http://example.com/wiki/apache-projects%2fcouchd%2f/info
Another use case is when you have to deal with attachments. For example if you want to build a TMS tilecache [1] bases on CouchDB. My URL would look like this (where "tile" is the attachement):
http://example.com/tilecache/3-5-2/tile
But I'd need an URL like
http://example.com/tilecache/tiles/3/5/2.png
(resp. http://example.com/tilecache/_design/tilecache/_rewrite/tiles/6/9/9.png)
My modification to the rewriter allows you to replace substrings with other ones. Here's the rewriter rule for this example:
{
"from" : "/tiles/<x>/<y>/<z>.png",
"to" : "..\\/..\\/:x/:y/:z/tile",
"replace": {
"old": "/",
"new": "-",
"limit": -1
}
}
It replaces all occurences of "/" with "-" on the "to"-path. Two slashes ("\\") escape a character, so it won't be replaced. The "limit" parameter specifies how many occurences should be replaced. It could be either positive, then it will just count how often a string was already replaced and stop at the limit. If "limit" is negative, it will count from the back. This is especially useful if you want to replace slashes and know how many slashes the attachment has, but not how many the document has.
> Ability to replace substrings in rewriter
> -----------------------------------------
>
> Key: COUCHDB-1006
> URL: https://issues.apache.org/jira/browse/COUCHDB-1006
> Project: CouchDB
> Issue Type: Improvement
> Components: Database Core
> Reporter: Volker Mische
> Priority: Minor
> Attachments: rewrite-replace.patch
>
>
> The current rewriter is bound to the parts of a path. Therefore I propose and additional "replace" property to be able to rewrite URLs beyond that limitation. One example would be subpages in a wiki, where each subpage corresponds to one document in the database. Here's an example:
> Desired URL:
> http://example.com/wiki/apache-projects/couchdb/info
> URL without rewriting:
> http://example.com/wiki/apache-projects%2fcouchd%2f/info
> Another use case is when you have to deal with attachments. For example if you want to build a TMS tilecache [1] bases on CouchDB. My URL would look like this (where "tile" is the attachement):
> http://example.com/tilecache/3-5-2/tile
> But I'd need an URL like
> http://example.com/tilecache/tiles/3/5/2.png
> (resp. http://example.com/tilecache/_design/tilecache/_rewrite/tiles/6/9/9.png)
> My modification to the rewriter allows you to replace substrings with other ones. Here's the rewriter rule for this example:
> {
> "from" : "/tiles/<x>/<y>/<z>.png",
> "to" : "..\\/..\\/:x/:y/:z/tile",
> "replace": {
> "old": "/",
> "new": "-",
> "limit": -1
> }
> }
> It replaces all occurences of "/" with "-" on the "to"-path. Two slashes ("\\") escape a character, so it won't be replaced. The "limit" parameter specifies how many occurences should be replaced. It could be either positive, then it will just count how often a string was already replaced and stop at the limit. If "limit" is negative, it will count from the back. This is especially useful if you want to replace slashes and know how many slashes the attachment has, but not how many the document has.
> [1] http://wiki.osgeo.org/wiki/Tile_Map_Service_Specification
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.