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]
