Any commercial shopping cart packages using postgresql?

Mike Nolan wrote:

I may need to move a web store to another hosting facility or rewrite it.

I'm currently exploring the Zelerate AllCommerce system
http://allcommerce.sourceforge.net

I haven't even reached the stage of installing it yet. It's designed to
run out-of-the-box on MySQL, so I'm a little wary of that (I'm still
recovering from reading taht MySQL Gotchas page). So this is just a
pointer to something that exists.

HTH
Alex

Mike,

You could take a look at:
http://www.oscommerce.com/
While it is not written for postgres but for mySql, it has all data base
access abstracted to a single include file, so it (potentially) could be
easy to adapt to postgres.
It is also not a finished project, but I think it's good enough already
for production usage.
Worths a look.

Just my 2c.

Csaba.

www.oscommerce.com

same thing. mySQL. Somebody did a postgres port. I have it up and running on postgreSQL (as of a week ago).

-----Original Message-----
From: Alex Satrapa [mailto:alex@lintelsys.com.au]
Sent: Wednesday, December 10, 2003 8:37 PM
To: Mike Nolan
Cc: pgsql-general@postgresql.org
Subject: Re: [GENERAL] Any commercial shopping cart packages using
postgresql?

Mike Nolan wrote:

I may need to move a web store to another hosting facility or rewrite it.

I'm currently exploring the Zelerate AllCommerce system
http://allcommerce.sourceforge.net

I haven't even reached the stage of installing it yet. It's designed to
run out-of-the-box on MySQL, so I'm a little wary of that (I'm still
recovering from reading taht MySQL Gotchas page). So this is just a
pointer to something that exists.

HTH
Alex

---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org

I used to follow the AllCommerce system quite closely, but I think
you'll find that it hasn't been actively developed for about 2 years now
IIRC. If that's not a problem for you then it's a good system, although
a little more complicated than I needed.

Regards

Tony

Alex Satrapa wrote:

Jeff,

When they did the port, did they also "do the right thing" with foriegn
keys, stored procs, etc? I've been following several ports of MySQL
packages to PG. The thing that distresses me (as I've said before) is
that 90% of these ports simply seem to port the existing system to a
different DB (it's cool to be different, etc) without taking advantage
of any of the benefits of a fully ORDBMS, most notably phpPgAdsNew.

This IMHO is an excercise in futility when an application can be made to
excel it's previous incantation.

Just for the record, if you're prepared to take a snapshot or a
milestone build of oSCommerce and stick with it, it can be very
rewarding. One of my customers is using a snapshot from earlier this
year and is very happy with it! But I'm anaware of the PG port that
Jeff mentioned.

Cheers

T.

Jeff Cave wrote:

When they did the port, did they also "do the right thing" with foriegn
keys, stored procs, etc?

No. The pg port was an unofficial thing and appears to be very much in its infancy. The objective of the individual who wrote it was to "get it working". While I haven't looked too closely at the port, I am fairly certain that there is not a single foreign key defined in the database. The one thing added, that is not available in the mySQL version is indexes. Certain indexes have been defined to speed up product searches.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Mon, 15 Dec 2003 09:13:49 +0000, Tony wrote:

excel it's previous incantation.

<aside>
The spelling is "its", not "it's".
"Its" is a possessive pronoun. "It's" is a contraction for "it is".
</aside>

- --
jimoe at sohnen-moe dot com
pgp/gpg public key: http://www.keyserver.net/en/
-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 5.0 OS/2 for non-commercial use
Comment: PGP 5.0 for OS/2
Charset: cp850

wj8DBQE/3eb7sxxMki0foKoRApu/AKCVL/new88PQ+4QvBk8Jb0433k0VgCg0UHS
k+SJpvG2UyALaATcQpF3X5I=
=OxRY
-----END PGP SIGNATURE-----

On Mon, 2003-12-15 at 11:53, James Moe wrote:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Mon, 15 Dec 2003 09:13:49 +0000, Tony wrote:

excel it's previous incantation.

<aside>
The spelling is "its", not "it's".
"Its" is a possessive pronoun. "It's" is a contraction for "it is".
</aside>

'tis not as simple as that my friend, 'tis really more a matter of
dialect.

http://www.word-detective.com/back-d.html#its

Robert Treat
--
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL

P.S. Hi Greg :-)

Are there any commercial web store/shopping cart packages or host sites
that run under PostgreSQL? I found one web store package in the pgsql
project archives, but it looks like it may need a lot of tinkering to get
it working.

http://www.fishcart.org
It runs with MySQL, PostgreSQL, Solid, Oracle and MSSQL.

With the latest version we ran into some minor issues with PostgreSQL but
those will be solved with the new release that is supposed to get out as
soon as all the latest features are fully tested.

B.

My previous query applies here too then...

Is the cart built using full features of PG or is it a port using
database abstraction libs with the same functionality as MySQL?

Obviously the power of PG lies in all the goodies MySQL doesn't yet have.

Cheers

T.

B. van Ouwerkerk wrote:

I didn't see your previous question.. but.. no.. it's not coded
specifically for PG if you mean you can use views etc out of the box. In
the past several portions of code have been added to make it run properly
with PG, while installing the cart those are configured on the fly.

I wouldn't be surprised if the developers decide to modify the cart to have
the PG goodies. But there is much more to consider then just using views etc.

Until the PG goodies are used nothing is stopping you to create views from
the current queries, or use any other PG specific feature if you like.

The power of FishCart lies in the fact that it has many features.

B.

At 15:13 16-12-2003 +0000, Tony (Unihost) wrote:

My previous query applies here too then...

Is the cart built using full features of PG or is it a port using
database abstraction libs with the same functionality as MySQL?

Obviously the power of PG lies in all the goodies MySQL doesn't yet have.

Another question is how many of those goodies are needed to run a shopping
cart app? I'm interested in using PG in large measure because that's what
our membership system is being written in, so I assume that tying the
shopping cart app into the rest of the system will be easier with a
PG-based app than with one that uses MySQL or some other data platform.
--
Mike Nolan

Alex Satrapa wrote:

I'm currently exploring the Zelerate AllCommerce system
http://allcommerce.sourceforge.net

Ick... this product is *so* the poster child of the MySQL generation:

#
# Table structure for table 'addresses'
#
CREATE TABLE addresses (
objid varchar(20) DEFAULT '' NOT NULL,
objclass varchar(20) DEFAULT '' NOT NULL,
objtype varchar(20) DEFAULT '' NOT NULL,
...
PRIMARY KEY objid
);

No foreign keys! Look at all those "DEFAULT '' NOT NULL" columns! What
are they thinking?

As penance for suggesting this product, I will clean up the SQL and at
least post my experiences with installing and using this product on
PostgreSQL.

-----Original Message-----
From: Alex Satrapa [mailto:alex@lintelsys.com.au]
Sent: Tuesday, December 16, 2003 7:24 PM
To: pgsql-general@postgresql.org
Subject: Re: [GENERAL] Any commercial shopping cart packages
using postgresql?

Alex Satrapa wrote:

I'm currently exploring the Zelerate AllCommerce system
http://allcommerce.sourceforge.net

Ick... this product is *so* the poster child of the MySQL generation:

#
# Table structure for table 'addresses'
#
CREATE TABLE addresses (
objid varchar(20) DEFAULT '' NOT NULL,
objclass varchar(20) DEFAULT '' NOT NULL,
objtype varchar(20) DEFAULT '' NOT NULL,
...
PRIMARY KEY objid
);

No foreign keys! Look at all those "DEFAULT '' NOT NULL"
columns! What
are they thinking?

The no foreign keys thing means RI is out the window, of course. A sea
of tables, floating in a soupy database fog of danger.

But as for the DEFAULT '' NOT NULL entries, CODD and Date eventually
decided that NULL data was a big mistake.
While SQL programmers are used to it, most end users with slim SQL
familiarity will be pretty shocked when:

SELECT COUNT(*) FROM addresses WHERE <column> = 'some_constant'

Added with

SELECT COUNT(*) FROM addresses WHERE NOT <column> =
'some_constant'

Is not equal to

SELECT COUNT(*) FROM addresses

I tend to agree that every column should have a default and not be
allowed to become NULL. Just to keep end-user astonishment at a
minimum.

Dann Corbit wrote:

But as for the DEFAULT '' NOT NULL entries, CODD and Date eventually
decided that NULL data was a big mistake.
While SQL programmers are used to it, most end users with slim SQL
familiarity will be pretty shocked when:

And so, too, will man people with little or no understanding of internal
combustion engines get surprised when their diesel engine explodes after
putting high-octane unleaded fuel into it...

I tend to agree that every column should have a default and not be
allowed to become NULL. Just to keep end-user astonishment at a
minimum.

The idea of NOT NULL is to make sure that *valid* stuff is put in. Most
of these columns are set to absolutely meaningless defaults, ensuring
that your database not only lacks referential integrity, but contains
nothing of value either!

If I had enough hair left, I'd be pulling it out right about now ;)

Alex

On Tue, Dec 16, 2003 at 07:37:33PM -0800, Dann Corbit wrote:

But as for the DEFAULT '' NOT NULL entries, CODD and Date eventually
decided that NULL data was a big mistake.

<snip>

I tend to agree that every column should have a default and not be
allowed to become NULL. Just to keep end-user astonishment at a
minimum.

Your argument does tend to support the idea that columns should not be
allowed to become NULL. That's what the NOT NULL attribute is for. But that
doesn't mean you should supply a default value. If the field is marked NOT
NULL and you forget to insert something, the statement should error out.
Silently filling with blanks is just waiting for a disaster to happen,
especially without RI.

Also, NULL does have some very useful situations, such as a BillID field for
a transaction that has not been billed yet. Using blanks means you would
have to invent a dummy bill '' to assign them to to satisfy foreign keys.
With NULL the problem does not exist.

Here's an idea, make all columns by default NOT NULL and add a new attribute
NULLABLE ;)
--
Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/

Ick... this product is *so* the poster child of the MySQL generation:

...

No foreign keys! Look at all those "DEFAULT '' NOT NULL" columns! What
are they thinking?

You'd be surprised what the schema of most MEDICAL apps looks
like (if they aren't built off MS ACCESS, that is...). And one
would think medical DB designers are wont to be paranoid about
quality/integrity of data ...

Karsten Hilbert, MD
www.gnumed.org
(we do try to do a better job and this list is invaluable for it)
--
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346

If you learned the correct way a hundred years ago there would be no issue.
This issue is the people who never learned or who have forgotten.

The useage rule I dimly remember was "Use 'its' as if you were using 'his'"

Rick

Robert Treat wrote:

On Mon, 2003-12-15 at 11:53, James Moe wrote:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

'tis not as simple as that my friend, 'tis really more a matter of
dialect.

http://www.word-detective.com/back-d.html#its

Robert Treat

--