Specify a custom document name containing spaces

> 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"

> 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 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).

On Wed, Nov 17, 2010 at 02:46, Christian Grün <christian.gruen at 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!

> > -- Daniël > > On Wed, Nov 17, 2010 at 02:46, Christian Grün <christian.gruen at 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 >> >

On Thu, Nov 18, 2010 at 01:04, Christian Grün <christian.gruen at 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 at 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:

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 at mailman.uni-konstanz.de > https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk > >

> 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.

> 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 at mailman.uni-konstanz.de > https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk > >

On Thu, Nov 18, 2010 at 14:08, Christian Grün <christian.gruen at 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 >