OK, maybe I am a bit stupid, but why would you want to move stores around?
Oliver
James Mason schrieb:
Oliver,
I think the central issue is that all of the resources in a store know what their scope is. If you need to change the scope of a store later it means touching every resource in the store. If the store interface was insulated from its scope it would make moving stores around a lot easier.
There are implications here for bindings, but since I've never played with bindings I can't comment on them :).
-James
On Fri, 2004-10-15 at 15:46, Oliver Zeigermann wrote:
I still am not quite sure what you are referring to. I do not see why it should be a problem to save binding information with each store. I also see do not see how the solutions should help with your initial problem of a read only store.
But, maybe this is just me. If the other get what you are after, no problem with me.
Oliver
Darren Hartford schrieb:
Looking to come to closure on this e-mail thread. I want to post to bugzilla the enhancement request.
Before I do, I want to make sure the language and description is correct. =============
Problem:
*Scope and URI Bindings are individual to each store, no central management of Scope and Bindings.
*Scope and bindings are saved differently for each individual store's nodestore configuration.
*No seperation of Scope/URI Bindings from the actual metadata causing problems with read-only configured metadata stores.
Solution: Option 1: Move all Scope and URI Bindings to the root nodestore. Option 2: Create a new centralized ConfigStore for configuration of Scope and URI Bindings with it's own storage medium configuration. =============
Would this sound correct James, Warwick, Oliver? -D
-----Original Message----- From: Warwick Burrows [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 13, 2004 12:05 PM To: 'Slide Users Mailing List' Subject: RE: read-only support (CD/DVD)
Yes, definitely, that information is probably in the bindings tables
(BINDINGS and PARENT_BINDINGS). And there are some issues with the design
right now that may benefit from what you're proposing. There's a problem at
the moment where, for jdbc stores, its assumed that the URIs for all
children of the jdbc store (in my case '/') are stored in the URI table, but
in cases where the child binding of the root is the mount point for another
store then these URIs aren't in the table. This may be because the URI of
the child store is assumed to be maintained by the child store itself. The
result is that the getID() call in the BD2RDBMSAdapter method finds no id
(returns 0) for the URI and the next call to use that id to get binding
information fails with an "id value out of range" type error. The workaround
is to skip further bind processing when the id is 0 and the stores seem to
come up and work with this workaround but there may be a greater design
issue there related to how child stores are tracked by the parent.
Warwick
-----Original Message-----
From: Darren Hartford [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 13, 2004 8:02 AM
To: Slide Users Mailing List
Subject: RE: read-only support (CD/DVD)
Warwick, With the jdbc stores, are any new tables created that might be saving similar information as those .def.xml files? My concern is that, as Oliver pointed out, this 'store78.def.xml' file is created and saved *only* where the metadata is saved for TxXMLFileDescriptor (no option to change that). Something similar must be happening with JDBC stores.
With James recommendation of having the scope node be part of the root store instead of the child store, the whereabouts of the JDBC version of this information would be valuable in determining if we can simply have this scope node information be part of the root's 'nodestore', or if there should be a new ScopeStore/ConfigStore that can be custom-configured.
Having this information stored only in the root node (using whatever the root's nodestore configuration) should satisfy read-only needs if this is the quicker solution, and I do not forsee any drawbacks outside of minor confusion as we have had on this thread.
-D
-----Original Message----- From: James Mason [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 13, 2004 1:48 AM To: Slide Users Mailing List Subject: Re: read-only support (CD/DVD)
Darren, I think the issue you're seeing is that the value you
enter for
the <scope> becomes part of the URI space in Slide. As Warwick and
Oliver mentioned, by defining a scope to be "store78" you've effectively
created a /store78 node with the contents of your store inside it. Since
the TxXMLFileDescriptorsStore uses a meaninfully named xml file to
represent each node, the store creates a store78.def.xml file.
I think earlier you were talking about insulating the store
from the
scope it was defined on. I think that would probably be a
good idea.
Effectively it would mean the store78 node would be part of
the root
store instead of the child store. I'm not sure what making
that change
would entail (maybe Oliver does).
For an immediate solution, if you create your store with the
same scope
you're planning on using after you burn your CD it should
mask this
problem (there may be others, though).
-James
On Tue, 2004-10-12 at 22:31, Oliver Zeigermann wrote:
Which is already there:
<parameter name="rootpath">e:/store/metadata</parameter>
By the way a description file of that fashion is
created for every
collection and content resource.
Oliver
Warwick Burrows schrieb:
So basically the creation of this store78.def.xml file
only occurs for
TxXMLFileDescriptorsStore type stores as I don't see it
for a jdbc root
store. But I do have two TxXMLFileDescriptorsStores
configured as well and I
do see .XML files for those. Eg.
store2/metadata/files_2.def.xml and
store3/metadata/files_secondCollection.def.xml. So a
parameter to the
TxXMLFileDescriptorsStore telling it where to put this
description file
would be sensible.
Warwick
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
