What I've seen in the DB2RDBMSAdapter is that there is a disconnect between the root and child stores in the storeObject()method when the parent is the root and is a jdbc store, and the child to be added to the binding table is a mount point for a child store. If there was a central store for scopes then I'm guessing that this child store would now have an entry in the root store's uri table and this particular problem would be solved.
As it is now, with the workaround I've added to fix the exception, there is no entry in the binding table for the "root->child_store_mount_point" relationship. Warwick > -----Original Message----- > From: Oliver Zeigermann [mailto:[EMAIL PROTECTED] > Sent: Friday, October 15, 2004 5:46 PM > To: Slide Users Mailing List > Subject: Re: read-only support (CD/DVD) > > > 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]
