Hi Dave,
sorry for the long delay, caused by the occidental winter break..
You've analyzed very well what are the inconsistencies between an
"empty database" and a database with one empty document – and I know
it's no real excuse that this issue hasn't caused any problems in our
own use cases. The basic reason why we have equalized an empty
document node with an "empty database" some time ago was that we
wanted to avoid too many new code snippets that dealt with the special
case of having stored no data at all.
In a nutshell, I completely agree that the solution you are proposing
would be more consistent, but I suspect that we'd need quite some time
to rework all the relevant lines of code. If you are interested in
tackling this challenge, I'll be more than glad!
Best,
Christian
___________________________
On Thu, Dec 29, 2011 at 4:36 PM, Dave Glick <dgl...@dracorp.com> wrote:
> Hello again,
>
> I've noticed some inconsistencies with regard to the initial document in an
> empty database. I understand that it is often treated as an indication that
> the database is "empty". I.e., if the database has only one node and it's a
> document at the first pre value, then Data.empty() returns true. The problem
> arises because the database isn't actually empty - it contains one empty
> document - and some commands/methods view it as an empty database while
> others treat it as a database with one empty document. Several examples:
>
> - The method Data.doc(name) will return -1 (indicating the document doesn't
> exist) while Data.docs() will return an array of size 1 with the first value
> a 0 (indicating there is one document at pre value 0). This is actually my
> own problem because the API I'm writing relies on these two methods being
> internally consistent - I can't have one telling me there is one document
> called "XYZ" but then have the other refuse to give me a pre value for the
> "XYZ" document I was just told exists.
> - The GUI shows a single doc node in the tree view but issuing the command
> "list [database name]" shows the database as having no resources.
> - I can evaluate the query "insert node 'text' into doc('[initial document
> name]')" and it executes. I can see the new text node under the initial
> document in the GUI tree view. Now when I issue the command "list [database
> name]" I see 1 resource. Having the list command report different numbers of
> resources before and after a XQuery insertion seems odd.
> - If I issue the command "ADD TO newdoc <xyz/>", I can see the new
> doc("newdoc") node with the child <xyz> element in the GUI but the previously
> empty document is now gone. This also seems odd - I'm not sure how I feel
> about an ADD command removing data from the database (even if it was just
> intended to be a placeholder).
>
> In the end, I think BaseX should support the notion of a database with one
> empty document as being valid - there are probably cases where one might want
> to start their session in that state. I'm not sure what the solution is or
> should be (or if it's even something that is worth or needs solving). My own
> preference would be for the internal indication of an empty database to use a
> different node kind dedicated for that purpose so there is no confusion
> whether the single node at pre 0 is an empty initial document or an
> indication of an empty database.
>
> At the very least, I think the inconsistencies above should be corrected - if
> a single empty document node is intended to signify an empty database and is
> not actually intended to be part of the database, then you should not see it
> in the GUI, not be allowed to insert content to it, etc.
>
> Dave
>
> _______________________________________________
> BaseX-Talk mailing list
> BaseX-Talk@mailman.uni-konstanz.de
> https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk
_______________________________________________
BaseX-Talk mailing list
BaseX-Talk@mailman.uni-konstanz.de
https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk
