Re: Slide Migration: File Dump and Store Change

[Julian]

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 
PUT&PROPATCH 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