[Zope] Storing Data inside Zope
Dylan Reinhardt
zope@dylanreinhardt.com
31 May 2003 10:19:46 -0700
Tom,
I've been spending a fair amount of time attempting to answer that very
set of questions. It shouldn't be necessary to set up an RDBMS just to
cook up a simple app that needs to store a small number of records.
I may have something to release late next week, but then again this
project been within a week of release for several months now. :-)
Drop me a line privately if I don't announce something by Friday and
I'll give you a copy of what I've got so far.
Dylan
On Sat, 2003-05-31 at 08:22, Tom P. Allred wrote:
> Just how bad an idea is it to use Zope object Properties to store
> numeric/text application data?
>
> My first Linux (or otherwise) Zope app will be a gratis case tracking system
> for a friend's small (himself plus 3 staff) law office. Other than setting
> up new clients and cases (maybe a few a day) the most frequent data changes
> will be adding new activity detail records which are small. Only a couple
> of reports are run each day. Overall transactions will be few and small.
>
> My initial idea was to use MySQL or PostgreSQL for data storage. While
> developing the framework of the app I want to be able to store/retrieve a
> few records for testing. Since every bit of Zope (HTML, DTML, Python, etc.)
> is new to me, every time I start to do something I have to learn something
> else first. I'm not complaining - that's how I expected it to be - but if I
> could sort of skip over learning ZSQL and defining/using MySQL tables right
> now and stay focused on my input forms and reports, then come back to data
> storage later, that would really nice. My plan is to use scripts for all
> I/O which would allow me to change I/O methods later without changing
> whatever code is calling the scripts. I considered using text files or XML
> data files within Zope for testing but in each case I'd have to write the
> parsing and update-data code myself which would take time and be thrown out
> later by the final ZSQL code.
>
> Then I thought about defining some object that takes Properties, adding
> Property names/types for (example) the client master record and saving that
> as a data template (not ZPT). Then each time there was a new entry I'd make
> a copy of the template and update the Properties using Zope's built-in APIs
> without ever giving the data objects any content. I think I could also use
> Zope catalog features for data searches.
>
> Without knowing more about Zope the only downside I see is the data being
> encapsulated in the app tree, therefore requiring any data to be purged
> before copying/exporting the app somewhere. It will also make the Zope
> object grow but adding data is going to make any database grow no matter
> which is used. I can also imagine there might be a philosophical point
> about keeping the data outside the Zope object. But is it a bad idea for
> some practical reason? That's a question with two branches. The first is,
> is it completely bad and I shouldn't do it even temporarily for testing?
> The second is, is it bad for production but okay for development/testing?
> If there isn't a good reason for not doing it then it would certainly be
> nice to be able to stay in Zope for everything so that only Zope would have
> to be installed to move the package to new machines and so I can stay on
> track without having to branch off into data storage issues. I was thinking
> about using the File object as my data object since it supports Properties.
> Any other suggestions?
>
> Thanks,
> Tom P. Allred, MCSE, RHCE, CCNA
> Allred Data Consulting, Inc.
> 704-633-0311 x826
> www.AllredData.com
> Tom@AllredData.com
>
>
> _______________________________________________
> Zope maillist - Zope@zope.org
> http://mail.zope.org/mailman/listinfo/zope
> ** No cross posts or HTML encoding! **
> (Related lists -
> http://mail.zope.org/mailman/listinfo/zope-announce
> http://mail.zope.org/mailman/listinfo/zope-dev )