[Zope] Is e-commerce feasible with Zope?

[Kevin Dangoor]

----- Original Message -----
From: "Diego Dainese" <xdsi@xddainese.unive.it>
To: <zope@zope.org>
Sent: Tuesday, February 08, 2000 5:00 AM
Subject: Re: [Zope] Is e-commerce feasible with Zope?


> On Mon, 7 Feb 2000 12:46:33 -0500 "Kevin Dangoor"
> <kid@kendermedia.com> wrote:
> > ----- Original Message -----
> > From: "Diego Dainese" <xdsi@xddainese.unive.it>
> > To: <zope@zope.org>
> > Sent: Monday, February 07, 2000 8:51 AM
> > Subject: [Zope] Is e-commerce feasible with Zope?
> >
> > I have implemented something like this for byproducts.com. I'm storing
the
> > carts in the ZODB. This is not desirable if your site is very busy,
though,
> > because there can be issues if you have lots of concurrent writes going
on.
> > (Note that, from what I've read in previous threads, I would have to
have 5
> > people create new shopping carts at the same instant in order for one of
> > them to run into an error. That's a lot. When I said that the site would
> > have to be very busy, I meant *very*.)
> >
>
> But are the Digital Creations guys aware of this problem, and thinking
> to a solution?
>
> In the short term I don't foresee a lot of traffic on my site, and I
> hope that in the long term the problem with ZODB will be fixed.

DC knows about this, but I'm not sure if there is a reasonable core-level
solution to it. The problem can be dealt with at the application level.

I sent a message to Pavlos yesterday where we talked about the problem in a
bit more detail (and tossed out the number "5" above). You really can have a
*whole bunch* of traffic before you'll run into a problem. And, after that,
if you just think of a good scheme to break the objects up into separate
containers, then there won't be any trouble.

>    "If the data is going to be frequently changing, then it's not a
>    good idea to put it in the ZODB. Every time the data changes, a new
>    record will be appended to the Data.fs file - this could become a
>    problem very quickly."
>
> Is this still true?

Yes, this is true of the FileSystem storage. (It is not true of the Berkeley
storage that Ty Sarna created.) Basically, this is a good reason not to do a
hit counter on every page that writes to properties in the ZODB. But, it may
not be too much of a problem with shopping carts. Sure, the Data.fs grows,
but not by a whole lot. Plus, the packing operation is largely done without
blocking access to your site.

Also, DC plans to make it possible to use multiple storages for one logical
object database. There are some heavy duty issues they need to work out
before that is possible though. Once it happens, you could use the
FileSystem storage for your relatively static content and BerkeleyStorage or
SQLStorage for frequently changing content. There are limitless
possibilities for dealing with these issues where the application demands
it.

> I'm very interested in these new user objects: where can I find more
> info on this subject?

Join the PTK mailing list, and take a look at the archives. There was a lot
of discussion about user objects last week. Well worth reading.

> Another concern with ZODB is the max DB size: on Linux based system
> with the ext2 file-system and the kernel patch, the max file size is 4
> GB; since the Zope DB is stored into a single file (right?), this mean
> that the max DB size is 4 GB.

I believe there are ways around this, but I'm not a linux guru.

> The solution I had in mind to store customer's account is a folder
> containing one instance of a custom ZClass to store general user
> information and one ore more instances of another custom ZClass to
> store address informations (do you known better solutions?).

The new user objects will have propertysheets, and that would likely be the
way to go.

Kevin