Specify a custom document name containing spaces
Hi everyone, I have a question regarding the add command -- ADD (AS [name]) (TO [target]) [input]. It seems it is not possible to add a document to the database which you want to give a custom name (for whatever reason) that contains a space like so: add as "test x.xml" "/path/to/test 1.xml" Doing this will result in an error implying I do not use the right syntax. Apparently it is not allowed to use quotes (neither " nor ') around the name you want to give the document. I wonder why this is. Especially because BaseX will actually name the document 'test 1.xml' when the 'as [name]' is omitted; like so: add "/path/to/test 1.xml" I wonder if this is a minor bug in the syntax checking of this command, or that this is intended behavior. In case of the latter, I wonder if there is another way to specify names which contain spaces. While we are at it (the add command): I was expecting the TO [target] part to refer to a database. For example, if I have two databases 'misc' and 'col', I would expect a command such as: add to misc "/path/to/test.xml" to add the document test.xml to the database misc. Instead, I first have to open the database misc, then add the document (without the 'to misc'-part), then close it again. Is this also intended? If so, please enlighten me as to what target exactly refers to (apparently no database/collection). Thanks in advance for any responses. -- Daniël ps. I am on version 6.3.1
Dear Daniël, thanks for your e-mail.
I have a question regarding the add command -- ADD (AS [name]) (TO [target]) [input]. It seems it is not possible to add a document to the database which you want to give a custom name (for whatever reason) that contains a space like so:
add as "test x.xml" "/path/to/test 1.xml"
To reduce the number of potential side effects, we have simplified the command parser to ignore special characters, including spaces. However, this is a useful hint, which I've just added to our todo list (similar issues will have to be checked on other commands, such as delete).
I wonder if this is a minor bug in the syntax checking of this command, or that this is intended behavior. In case of the latter, I wonder if there is another way to specify names which contain spaces.
Currently, you could use the BaseX API and the Add command (new Add(...)...) to specify names with spaces.
While we are at it (the add command): I was expecting the TO [target] part to refer to a database. For example, if I have two databases 'misc' and 'col', I would expect a command such as:
add to misc "/path/to/test.xml"
The TO option allows you to specify a target path within the currently opened database. This was a frequent feature request, as the source and target path may be different.. add to path/one "path/two/test.xml" Next, we have decided to limit the ADD command to operate on a single database instance, as the combination of the database name, target path and input data could lead to confusion. Last but not least, the adding of single documents will be faster if the database is opened only once. Hope this helps, Christian
Hi Christian, Thank you for your fast response, you cleared it up.
To reduce the number of potential side effects, we have simplified the command parser to ignore special characters, including spaces. However, this is a useful hint, which I've just added to our todo list (similar issues will have to be checked on other commands, such as delete).
The delete command seems to work fine with arguments surrounded by quotes -- allowing you to delete documents with spaces without problems. If I notice a similar issue in any other command(s) I will let you know! -- Daniël On Wed, Nov 17, 2010 at 02:46, Christian Grün <christian.gruen@gmail.com> wrote:
Dear Daniël,
thanks for your e-mail.
I have a question regarding the add command -- ADD (AS [name]) (TO [target]) [input]. It seems it is not possible to add a document to the database which you want to give a custom name (for whatever reason) that contains a space like so:
add as "test x.xml" "/path/to/test 1.xml"
To reduce the number of potential side effects, we have simplified the command parser to ignore special characters, including spaces. However, this is a useful hint, which I've just added to our todo list (similar issues will have to be checked on other commands, such as delete).
I wonder if this is a minor bug in the syntax checking of this command, or that this is intended behavior. In case of the latter, I wonder if there is another way to specify names which contain spaces.
Currently, you could use the BaseX API and the Add command (new Add(...)...) to specify names with spaces.
While we are at it (the add command): I was expecting the TO [target] part to refer to a database. For example, if I have two databases 'misc' and 'col', I would expect a command such as:
add to misc "/path/to/test.xml"
The TO option allows you to specify a target path within the currently opened database. This was a frequent feature request, as the source and target path may be different..
add to path/one "path/two/test.xml"
Next, we have decided to limit the ADD command to operate on a single database instance, as the combination of the database name, target path and input data could lead to confusion. Last but not least, the adding of single documents will be faster if the database is opened only once.
Hope this helps, Christian
The delete command seems to work fine with arguments surrounded by quotes -- allowing you to delete documents with spaces without problems. If I notice a similar issue in any other command(s) I will let you know!
Thanks for the information. We have updated the commands and fixed your issue (and some minor other inconsistencies). Christian
-- Daniël
On Wed, Nov 17, 2010 at 02:46, Christian Grün <christian.gruen@gmail.com> wrote:
Dear Daniël,
thanks for your e-mail.
I have a question regarding the add command -- ADD (AS [name]) (TO [target]) [input]. It seems it is not possible to add a document to the database which you want to give a custom name (for whatever reason) that contains a space like so:
add as "test x.xml" "/path/to/test 1.xml"
To reduce the number of potential side effects, we have simplified the command parser to ignore special characters, including spaces. However, this is a useful hint, which I've just added to our todo list (similar issues will have to be checked on other commands, such as delete).
I wonder if this is a minor bug in the syntax checking of this command, or that this is intended behavior. In case of the latter, I wonder if there is another way to specify names which contain spaces.
Currently, you could use the BaseX API and the Add command (new Add(...)...) to specify names with spaces.
While we are at it (the add command): I was expecting the TO [target] part to refer to a database. For example, if I have two databases 'misc' and 'col', I would expect a command such as:
add to misc "/path/to/test.xml"
The TO option allows you to specify a target path within the currently opened database. This was a frequent feature request, as the source and target path may be different..
add to path/one "path/two/test.xml"
Next, we have decided to limit the ADD command to operate on a single database instance, as the combination of the database name, target path and input data could lead to confusion. Last but not least, the adding of single documents will be faster if the database is opened only once.
Hope this helps, Christian
Hi Christian, Thank you for the quick update of BaseX. I just tried 6.3.2, but this command (on Windows) still fails: add as "test 2.xml" "D:\test 1.xml" The command parser seems to not accept the quotes surrounding the [name] part. Perhaps I misunderstood you when you said the issue was fixed, did you refer to another issue? Kind regards, Daniël On Thu, Nov 18, 2010 at 01:04, Christian Grün <christian.gruen@gmail.com> wrote:
The delete command seems to work fine with arguments surrounded by quotes -- allowing you to delete documents with spaces without problems. If I notice a similar issue in any other command(s) I will let you know!
Thanks for the information. We have updated the commands and fixed your issue (and some minor other inconsistencies). Christian
-- Daniël
On Wed, Nov 17, 2010 at 02:46, Christian Grün <christian.gruen@gmail.com> wrote:
Dear Daniël,
thanks for your e-mail.
I have a question regarding the add command -- ADD (AS [name]) (TO [target]) [input]. It seems it is not possible to add a document to the database which you want to give a custom name (for whatever reason) that contains a space like so:
add as "test x.xml" "/path/to/test 1.xml"
To reduce the number of potential side effects, we have simplified the command parser to ignore special characters, including spaces. However, this is a useful hint, which I've just added to our todo list (similar issues will have to be checked on other commands, such as delete).
I wonder if this is a minor bug in the syntax checking of this command, or that this is intended behavior. In case of the latter, I wonder if there is another way to specify names which contain spaces.
Currently, you could use the BaseX API and the Add command (new Add(...)...) to specify names with spaces.
While we are at it (the add command): I was expecting the TO [target] part to refer to a database. For example, if I have two databases 'misc' and 'col', I would expect a command such as:
add to misc "/path/to/test.xml"
The TO option allows you to specify a target path within the currently opened database. This was a frequent feature request, as the source and target path may be different..
add to path/one "path/two/test.xml"
Next, we have decided to limit the ADD command to operate on a single database instance, as the combination of the database name, target path and input data could lead to confusion. Last but not least, the adding of single documents will be faster if the database is opened only once.
Hope this helps, Christian
Thank you for the quick update of BaseX. I just tried 6.3.2, but this command (on Windows) still fails:
Yes, that version was released before the fix; you're welcome to check our sources from the svn repository. As an alternative, you can wait for the next minor release, or I can provide you with a jar snapshot. Christian
Hi, while everyone can simply check out basex, the access to basex-api svn seems to be restricted. When using maven for your application, there's a transient dependency in basex-api 6.3.2 requiring the basex 6.3.2 jar, which makes it impossible to use the only accessible version of basex-api (e.g. 6.3.2) with the checked out version of basex.jar (e.g. 6.3.3) (installed into local mvn repository). Could you provide read-only access to basex-api svn? That'd be great. Thanks! -- Thomas Praxl -------------------- macrominds (Inh. Thomas Praxl) Tunnelstraße 15 35321 Laubach 06405 50 25 35 http://www.macrominds.de On 18.11.2010 14:08, Christian Grün wrote:
Thank you for the quick update of BaseX. I just tried 6.3.2, but this command (on Windows) still fails:
Yes, that version was released before the fix; you're welcome to check our sources from the svn repository. As an alternative, you can wait for the next minor release, or I can provide you with a jar snapshot.
Christian _______________________________________________ BaseX-Talk mailing list BaseX-Talk@mailman.uni-konstanz.de https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk
Hi Thomas,
while everyone can simply check out basex, the access to basex-api svn seems to be restricted. [...] Could you provide read-only access to basex-api svn? That'd be great.
The svn repository of the basex api should be available to everyone; it can also be viewed online: https://svn.uni-konstanz.de/dbis/basex/trunk/api/ If I'm wrong, feel free to correct me (..does someone else encounter similar problems here?) Next, thanks for your patch; I'm working on it, Christian
Hi Christian, sorry, I just didn't use the correct URL. My mistake (would be nice to have it on the website though). Thanks for the info. Everything works fine now. Greetings -- Thomas
Hi Thomas,
while everyone can simply check out basex, the access to basex-api svn seems to be restricted. [...] Could you provide read-only access to basex-api svn? That'd be great.
The svn repository of the basex api should be available to everyone; it can also be viewed online:
https://svn.uni-konstanz.de/dbis/basex/trunk/api/
If I'm wrong, feel free to correct me (..does someone else encounter similar problems here?)
Next, thanks for your patch; I'm working on it, Christian _______________________________________________ BaseX-Talk mailing list BaseX-Talk@mailman.uni-konstanz.de https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk
Hi Christian, Thank you for the offer, but as I do not use the feature currently -- I just stumbled upon it during some testing :) -- I will simply wait for the next minor release. Ciao, Daniël On Thu, Nov 18, 2010 at 14:08, Christian Grün <christian.gruen@gmail.com> wrote:
Thank you for the quick update of BaseX. I just tried 6.3.2, but this command (on Windows) still fails:
Yes, that version was released before the fix; you're welcome to check our sources from the svn repository. As an alternative, you can wait for the next minor release, or I can provide you with a jar snapshot.
Christian
participants (4)
-
Christian Grün -
Daniël Knippers -
Thomas -
Thomas Praxl