This sounds good to me. Keep in mind this will likely have to wait until 3.0 as it will probably break compatibility with existing stores.
-James On Fri, 2004-10-15 at 13:20, Darren Hartford wrote: > 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]
