Not that my opinion matters much :), but I'm not sure what the advantages of a database are for files. The performance of a database for file retrieval is less than that of file system access. You are not planning to use the database for what it is good for (queries). You would have to write tools to make file update to the database as simple as file system updates...etc. So, if all you are trying to accomplish is a simple way to update server files then it would seem that you would want to set up a context that points to an unpacked location and never use wars (they offer no real advantage other than packaging anyway). I suppose you could just zip the files if portability is an issue. From a dev process standpoint, you either have a separate dev directory and "deploy" into the live directory. Or, you work off of the live directory (not a good idea in production :)). If you are worried about multiple systems having the same code base, then there are plenty of file system replication tools around (sharing files on a network share for running servers is a bad idea due to the affects contention can have on system functionality and performance). Now, with your cvs solution, it would be very easy to use your automated build process to retrieve the latest code from cvs and move it into the appropriate file system location (context docbase) and then stop and restart the server or reload the app. Again, I would not recommend this kind of instability for a production system. It is too hard to track bugs. For development, though, it is advantageous.
So, I suppose what I am asking is -- what do you have against file systems? They are really well optimized for files. :) LES -----Original Message----- From: Anthony Eden [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 10, 2003 2:44 PM To: [EMAIL PROTECTED] Subject: Re: [OS-webwork] JavaOne meetings + Michael Blake Day wrote: > Right, but I've always been against sticking templates into a relational > database system, and I've never heard of any other good alternative database > for document storage. First of all I have to ask: why won't you store a template in a relational database? As for alternatives I am particularly fond of the Virtual File System approach (using Commons VFS). To your application everything looks like a file system yet you could potentially store "files" anywhere. > I suppose that using an unpacked WAR is one solution, but what about the > issue of security? Content people should not have write access to the > unpackaged WAR directory. Does anyone else accomplish this without a > relational database? Unpacked WARs are probably the worst solution unless your file system is the definitive location of that content. If there is any chance that you might want to update the file system using a new WAR in the future then you would potentially lose the existing data or you would have to jump through hoops to migrate it. One thing I have been considering for quite some time is the ability to pull content directly from CVS. Perhaps that is the alternative that you are looking for? Although like I said before I don't understand what you have against databases. Sincerely, Anthony Eden ------------------------------------------------------- This SF.net email is sponsored by: Etnus, makers of TotalView, The best thread debugger on the planet. Designed with thread debugging features you've never dreamed of, try TotalView 6 free at www.etnus.com. _______________________________________________ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork ------------------------------------------------------- This SF.net email is sponsored by: Etnus, makers of TotalView, The best thread debugger on the planet. Designed with thread debugging features you've never dreamed of, try TotalView 6 free at www.etnus.com. _______________________________________________ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
