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]
