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?
The script will add the product to a shopping basket; later the customer can proceed to the checkout. Here she/he will be able to create an account on our site for later shopping.
What I need is:
- A means to implement the basket; with Apache+PHP I would use a simple file containing a list of product codes, or an SQL table.
- A means to set a cookie on the client browser and to associate the it with a basket; with Apache+PHP I would use a SQL relation cookie->basket, or I would put in relation the basket filename with the cookie.
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. However there's another thing that concern me on the ZODB based solution; from on the ZODB vs SQL HOWTO: "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?
There are two Zope products, FSSession and SQLSession which should handle these things quite easily for you.
OK, I'm sure one of these will solve the problem.
- A means to store the products database; with Apache+PHP I would use a simple SQL DBMS.
You could store the products database in the ZODB or in a SQL DB. Which one you use will probably depend on what you want to do with it, and how updates are made to it. For example, if you were going to be doing something like reloading the entire DB every hour (not likely, but just in case you were), you would not want to use the ZODB with the FileSystem storage, because your Data.fs file will grow quickly and need frequent packing.
Zope makes it easy to go either way on this one.
I don't think the data will change so often; probably ZODB is the right solution for this.
- A means to store customer informations on the site; with Apache+PHP I would use another SQL table, with a relation one to many to store the (possibly) many customer's addresses.
Again, you can use SQL if you want. There's a whole bunch of work going on right now to create new User objects in Zope. These will make it possible to attach all sorts of things to users and will be a really nice abstraction.
I'm very interested in these new user objects: where can I find more info on this subject?
Personally, I prefer to work with the ZODB wherever possible. I just generally prefer objects to the relational model.
I prefer it too when possible. 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. 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?). But a quick test has revealed me that with this system, a user account will take about 2 kByte; with a max DB size of 4 GB this lead to max 2.000.000 users; this is for sure a big number, but if you consider the probable big number of dummy registrations, I think it's not unreachable. Is this analysis correct?
- I would let the site to be accessed both via https and http.
There was recently a ZServer version announced with support for SSL. Otherwise, I think people are just using Apache with fastcgi.
Glad to hear this!
- The site must be easily internationalized, thus I must be able to replace all the text in the pages with a translated version; with Apache+PHP I would use an include file where to store the text messages as PHP constants.
There is a Zope Internationalization Project (ZIP), though I think that has focused on adding more internationalization to Zope's core. For your own apps, I would think there are a number of ways to implement this. Acquisition is your friend. You'll probably use acqusition to make life easy for you.
OK; the solution I have in mind is to store the page's text into the folder's proprieties, but I am wondering if there is a coolest solution. Thank you for the reply, bye -- Diego | To reply remove the `x' and swap the | Sorry for my Dainese | words around the `@' in the address. | bad English.
At 11:00 Uhr +0100 08.02.2000, Diego Dainese wrote:
On Mon, 7 Feb 2000 12:46:33 -0500 "Kevin Dangoor"
There are two Zope products, FSSession and SQLSession which should handle these things quite easily for you.
OK, I'm sure one of these will solve the problem.
I guess SQLProperties <http://www.zope.org/Members/anthony/software/SQLProperties> use an interesting OO-based approach to this... anyone did a MySQL schema for them :-/
Again, you can use SQL if you want. There's a whole bunch of work going on right now to create new User objects in Zope. These will make it possible to attach all sorts of things to users and will be a really nice abstraction.
I'm very interested in these new user objects: where can I find more info on this subject?
This will be in the PTK <http://www.zope.org/Products/PTK> at the moment, there are some problems with PTK, so you might want to wait a little bit longer...
Personally, I prefer to work with the ZODB wherever possible. I just generally prefer objects to the relational model.
I prefer it too when possible.
See above (SQLProperties) for something inbetween. Jochen
----- 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
On Tue, 8 Feb 2000, Kevin Dangoor wrote:
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.
*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.
I think Kevin is right. If you device some simple hashing scheme for your users, lets say by doing a checksum on their names or use some combination of the letters then you would really need *many* concurrent hits to see a problem. I also think that some common ConflictErrors should be dealt at Zope level and not in the application. For instance the above mentioned problem, but from Kevin's email it seems that some simple cases like ConflictError arising from adding objects to folders simultaneously, are intellegently handled. Note also that if you use an RDBMS or even the filesystem you won't get into problems with concurrent users. OTOH its convenient to have things in ZODB.
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 think when multiple storages become available a lot of current problems will become trivial to implement, like as you have mentioned, an efficient hit counter. Pavlos
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.
Well, consider that with a site that is getting the insane traffic level being tossed around here to really incur problems, no pansy machine will be able to handle it. For something that size, I'd reccomend an Alpha processor powered machine, where there is essentially no file size limit in Linux. Proces are quite comparative now, too. -- In flying I have learned that carelessness and overconfidence are usually far more dangerous than deliberately accepted risks. -- Wilbur Wright in a letter to his father, September 1900
At 11:02 AM 2/8/00 -0500, Kevin Dangoor wrote:
The new user objects will have propertysheets, and that would likely be the way to go.
Well, they will if Ty and I can figure out how to do them properly, or someone else volunteers to do it. :) Unfortunately, as best as I can tell there are two semi-compatible models in Zope for what propertysheets *are*, and it's not clear what exactly we should implement for the user objects. I don't really want to create a *third* model. :(
On Tue, 8 Feb 2000 11:02:26 -0500 "Kevin Dangoor" <kid@kendermedia.com> wrote: [...]
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.
OK. [...]
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.
This would be very cool :-) +++ I'm still not sure if I will go on with Zope for this project (my boss is pushing me to meet the deadline, no matter the tool I use) but I will for sure keep an eye on its development. Thank you all for the replies, bye -- Diego | To reply remove the `x' and swap the | Sorry for my Dainese | words around the `@' in the address. | bad English.
participants (6)
-
Bill Anderson -
Diego Dainese -
Jochen Haeberle -
Kevin Dangoor -
Pavlos Christoforou -
Phillip J. Eby