Re: [Exist-open] exist aborts storing well formed XML

[Ihe O. <ihe...@gm...>]

No need to speculate as to what Codd meant when we can refer to his seminal
paper - A Relational Model of Data for Large Shared Data Banks.

*1.2.2. Indexing Dependence. In the context of formatted data, an index is
usually thought of as a purely performance-oriented component of the data
representation. It tends to improve response to queries and updates and, at
the same time, slow down response to insertions and deletions. From an
informational standpoint, an index is a redundant component of the data
representation. If a system uses indices at all and if it is to perform
well in an environment with changing patterns of activity on the data bank,
an ability to create and destroy indices from time to time will probably be
necessary. The question then arises: Can application programs and terminal
activities remain invariant as indices come and go? *

There are already enough clues there as to where he is headed but towards
the end of the next paragraph

*".....Application programs taking advantage of the performance benefit of
these indexing chains must refer to those chains by name. Such programs do
not operate correctly if these chains are later removed."*

Having been an IDMS programmer at the start of my career I know that this
is referring to database query access that explicitly referenced specific
indexes - so to use an index you would have to code "Obtain foo using
idx-bar" and if you removed (or maybe changed) the index idx-bar you could
expect the program to stop working.

Raising the level of abstraction just a teeny bit I'd say given the
appearance of phrases like "purely performance-oriented component" and
"redundant component of the data representation" Codd doesn't think that
the presence of absence of an index or anything connected with it  should
interfere with the correct working of an application. If there is any doubt
about that I would refer to the first sentence in the abstract.

*"Future users of large data banks must be protected from having to know
how the data is organized in the machine (the internal representation)."*

The data I tried to store was a well-formed XML document tiny in size (582
bytes to be precise).

A correctly functioning XML repository should store it without complaint
and anything else that is or has been stored in that repository should be
 irrelevant.

Correct me if I am wrong but the opposing argument seems to be we don't
agree with that because we don't agree with your design choices.



On Fri, Feb 27, 2015 at 8:37 AM, Jens Østergaard Petersen <oe...@gm...
> wrote:

> This rule says that the application must not make reference to physical
> entities such as locations on a hard disk. It does not say that SQL should
> run without physical constraints, only that SQL as a language must not
> concern itself with physical implementation. Databases before Codd referred
> to the physical file structure when storing and accessing – we are so far
> beyond that that it is hard to imagine – so the rule says that changes to
> how data is stored or accessed must not require you to change the SQL
> application.
>
> Jens
>
> On 27 Feb 2015 at 14:19:15, Ihe Onwuka (ihe...@gm...) wrote:
>
> http://www.tutorialspoint.com/dbms/dbms_codds_rules.htm
>
> See Rule 8.
>
> Any good reason why that should only be applicable to relational databases.
>
> On Fri, Feb 27, 2015 at 12:27 PM, Dmitriy Shabanov <sha...@gm...>
> wrote:
>
>>
>> On Fri, Feb 27, 2015 at 3:21 PM, <wol...@gm...> wrote:
>>
>>> > Agreed. I think we should change the storage for this from 16 bit to
>>> > 32 bit, although I would be interested to hear Wolfgang's opinion on
>>> > that.
>>>
>>> Increasing the symbol table to 32 bit would not only add 2 bytes to
>>> every element/attribute stored in dom.dbx. More important, it would also
>>> increase the key size used in the structural index as well as other indexes
>>> (if they operate on qnames). I don’t say that switching to 32 bit is out of
>>> question or difficult in any way. But if it is changed, I would definitely
>>> insist on a configuration option, because - as Jens noted - the issue
>>> likely affects only a very small fraction of use cases out there (I’ve
>>> never hit the limit with any standard XML schema in 10 years, though this
>>> does certainly not mean it’s impossible - as the current example
>>> demonstrates).
>>>
>>
>> And increase on 2 bytes will not solve problem that Ihe that eXist should
>> allow to store till hdd have free space. Tool misuse IMHO.
>>
>> --
>> Dmitriy Shabanov
>>
>>
>> ------------------------------------------------------------------------------
>> Dive into the World of Parallel Programming The Go Parallel Website,
>> sponsored
>> by Intel and developed in partnership with Slashdot Media, is your hub
>> for all
>> things parallel software development, from weekly thought leadership
>> blogs to
>> news, videos, case studies, tutorials and more. Take a look and join the
>> conversation now. http://goparallel.sourceforge.net/
>> _______________________________________________
>> Exist-open mailing list
>> Exi...@li...
>> https://lists.sourceforge.net/lists/listinfo/exist-open
>>
>>
> ------------------------------------------------------------------------------
>
> Dive into the World of Parallel Programming The Go Parallel Website,
> sponsored
> by Intel and developed in partnership with Slashdot Media, is your hub for
> all
> things parallel software development, from weekly thought leadership blogs
> to
> news, videos, case studies, tutorials and more. Take a look and join the
> conversation now.
> http://goparallel.sourceforge.net/_______________________________________________
> Exist-open mailing list
> Exi...@li...
> https://lists.sourceforge.net/lists/listinfo/exist-open
>
>