Miguel,
Thanks for all the help. I will first try to see about the migration then
decide on the most appropriate solution. It would seem to me however that a
database approach may be best for the metadata in a clustered environment,
while still storing the files on a file server. Do you have any thoughts
regarding this. Otherwise, thanks again.
Julian
- Original Message
From: Miguel Figueiredo [EMAIL PROTECTED]
To: Slide Users Mailing List slide-user@jakarta.apache.org; Julian [EMAIL
PROTECTED]
Sent: Friday, May 19, 2006 11:45:02 AM
Subject: RE: Slide Migration: File Dump and Store Change
Hello Julian,
Unfortunally I don't have any benchmark numbers. Anyway, you can still
check this address http://wiki.apache.org/jakarta-slide/SlideInProduction
where you can confirm that there many people using TxStore for production
scenarios.
Slide does have a cache mechanism and it's in part the reason why database
and TxStore are more or less equivalent in performance: once the
metainformation data is read, it is returned from the cache instead of the
store. As an aside, there were some tests where we found out that one DB
Store (postgres or mysql, don't remember well) would significantly perform
worst than TxStore.
Hope this helps,
Miguel Figueiredo
-Original Message-
From: Julian [mailto:[EMAIL PROTECTED]
Sent: sexta-feira, 19 de Maio de 2006 15:38
To: Slide Users Mailing List
Subject: Re: Slide Migration: File Dump and Store Change
Hi,
Thanks for the help. Do you have any metrics that indicate that the
database is a better solution? Is the database folder structure cached like
the XML folder structure so that if I change the meta data in the database,
it isn't reflected in the runtime until a server restart?
Thanks
!-- _filtered {font-family:Tahoma; panose-1:2 11 6 4 3 5 4 4 2 4;} /*
Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {margin:0cm;
margin-bottom:.0001pt; font-size:12.0pt; font-family:Times New Roman;}
a:link, span.MsoHyperlink {color:blue; text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed {color:purple;
text-decoration:underline;} span.EmailStyle17 { font-family:Arial;
color:navy;} _filtered { margin:70.85pt 3.0cm 70.85pt 3.0cm;} div.Section1
{} --Hello Julian,
Then your right. safe way to do things is make an automatic repository
browser-copier: for each folder recursively find child resources and
PUTPROPATCH them into the new repository. Only PUTs and PROPATCHs should be
needed if you are not using any of the other 'advanced' features like
versioning and access control.
Are you sure that you want to use a database? From my experience,
TxStores are more robust AND don't really loose performance. maybe you would
like to do a benchmarking.
Hope this helps,
Miguel
From: Julian [mailto:[EMAIL PROTECTED]
Sent: quinta-feira, 18 de Maio de 2006 17:17
To: Miguel Figueiredo
Subject: Re: Slide Migration: File Dump and Store Change
Miguel,
I believe it was Slide 1.0.16, which is not compatible and would require a
heavy transformation of data to be compatible. The other problem is how to
get it into the database format instead of the XML format. This leads me to
believe a GET, PUT, and PROPFIND, etc. will be required.
Thanks,
Julian
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
