Ah, thanks for having enlightened me! Now I have got it and it makes
sense to me.
Thanks for your patience as well :)
Oliver
Darren Hartford schrieb:
Moving the stores (and related scope) are the premise of Hierarchical Storage Management (nowadays also called Information Lifecycle Management I beleieve). Rather than give the academic version, here is an example use-case:
You start storing files with very fast access on the local harddrive (limit of 20G let's say). After three years of data you are at 18G, you have to do something with the data (2000, 2001, 2002 data, each at 6G).
So, you take 2000 and 2001 years of that data and move it to a remote share or a NAS for access. Now, previously all three years may have been under one scope (because you didn't plan ahead let's say). Now seperating the data out by year, you can create another scope for just '2000', '2001' that points to the respective stores on the NAS.
After the data becomes three years old, due to business contracts, the data does not have to be on expensive, high-speed equipment but it is required to be on CD or DVD to maintain its original state (and protected against tampering, viruses, etc) and be called upon to go back online (or always be online with a jukebox, just slower). Now, back in 2000, CD media was much more cost-effective than DVD, so to make it consistent you make one CD per month for 2000. Now these CD's will each have their own stores, so now you have 2000JAN, 2000FEB, 2000MAR, etc. for scopes for each CD.
Couple of years later, DVD is much better priced. So, being much smarter and wanting to maintain digital preservation and refresh the data on newer media, reduce the amount of media you have, and migrate off that aging CD jukebox that has started to cause you problems, you take the 2000-series CD's by month and convert them into quarterly DVD's and put them in you new DVD Jukebox. Now the scopes of those stores become 2000Q1, 2000Q2, 2000Q3, 2000Q4.
All the exact same files, same metadata, just the content of individual stores and their related scope has changed as the files themselves have been moved around over the lifetime of the data (and, more than likely, their related nodestores from JDBC, to Tamino, to XMLFileDescriptor, to even-faster-nodestore-medium....).
Hope this helps!
-D
-----Original Message-----
From: Oliver Zeigermann [mailto:[EMAIL PROTECTED]
Sent: Sat 10/16/2004 4:10 AM
To: Slide Users Mailing List
Cc:
Subject: Re: read-only support (CD/DVD)
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]
------------------------------------------------------------------------
---------------------------------------------------------------------
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]
