[support] Seeking Advice on Integrating drupal

[Christopher M. Jones]

I appreciate everyone's advice. You've been very helpful. I suspect that
our spec probably is less rigid than what I made out. We'll know more as
we find out more about what this client actually wants. Either way, I
think we're still pushing for Drupal.

There's just one last thing: what are we going to face as we look at
implementing a sell cart? That is, in addition to the traditional buy
cart, where customers save items they want to purchase from the company,
we need a sell cart where customers place items they want to sell to the
company for a set price. Is this going to be a quick hack, or not?


On Wed, 2008-05-28 at 10:52 +0200, Ivan Sergio Borgonovo wrote:
> On Tue, 27 May 2008 08:39:22 -0400
> "Christopher M. Jones" <cjones at partialflow.com> wrote:
> 
> > Very helpful. Thank you. In view of the fact that precisely what
> > we're looking to avoid is the cost of creating a new engine, what
> > about other solutions? We like Drupal. And if the tweaks we need
> > were simple we'd love to contribute. But if that's just not
> > realistic, then what about eCommerce? I steered clear of it,
> > because reviews of it seemed a bit luke warm. And then there's Zen
> > Cart, which I can't really get a good feeling for, since they seem
> > to have removed their documentation so you have to buy their book.
> > That doesn't give me a lot of confidence. 
> 
> At a first sight none of them actually reach that level of
> "consistency".
> I'd like to sit down and just see pieces of software gluing up by
> themselves and get the money for my contemplation of the Open Source
> Universe... <g> but since I had strict requirement on constrains on
> orders I had to sit down and write my own e-commerce engine and I
> used Drupal at where it is good at: CMS and community plumbing...
> plus the fact you get form validation and anti-tampering, theming...
> and PostgreSQL at where it is good at (coherency, transactions,
> fun to program).
> 
> If your MS SQL box is in proximity of your web server (to avoid
> latency etc...) you may put the e-commerce logic in MS SQL and use
> Drupal with mysql or postgresql as the display layer.
> That's exactly what I did at the beginning.
> I think putting products in nodes and recycling taxonomy doesn't
> offer enough advantages compared to performance impact and it can't
> be tuned as much as a general e-commerce site require (at least...
> integrating nodes and products in a good way required more time than
> just writing a "product" hook).
> If you need full text search on the catalogue you'll end up using the
> one offered by the DB if you've a high traffic website.
> MS SQL have a pretty different logic for paging and I think adodb
> drivers are the ones that exploit it better.
> 
> Zencart offer a basic CMS as other products do. I was looking for a
> more complete CMS.
> 
> Without Drupal and PostgreSQL I wouldn't have been able to write such
> feature rich software in such a "short" time.
> You may:
> a) reconsider your requirements. Are they really so strict?
> If the traffic is not going to be so high etc..., the chances that
> someone will order the same products at an enough near time to cause
> inaccuracy may be negligible.
> One thing is displaying the available quantity at a certain time,
> another is closing an order trying to avoid "overbooking", another
> one is closing an order *being sure* you didn't "overbook".
> b) write your own solution. This is not going to be cheap and you'll
> have to consider Drupal release cycle and your development time and
> your "time to market".
> c) dig deeper in Ubercart/Zen/OsCommerce and prove I was wrong and
> they can actually be tuned to meet such strict requirements in a 2
> DB scenario or they already do what you need.
> 
> If you chose b) you could:
> - use mysql/postgresql as Drupal DB and MS SQL as the e-commerce
> engine DB. This is a feasible choice just if your MS SQL is in
> proximity with your web server. Consider also security concerns.
> You'll end up in exploiting some of the characteristics of the DB
> because you'll need transactions and locking etc...
> When you'll need more Drupal/e-commerce integration... porting your
> code from MS SQL to pgsql or mysql may take time.
> - write your sync logic and move everything in mysql/pgsql.
> 
> Still, if you *really* need up to the second inventory and your data
> are on a MS SQL server you're going to write your own purchase logic
> to be sure that orders contains really available items.
> The most frequent scenario is... they have their 3rd party closed
> source accounting application on that MS SQL and this is not going
> to help.
> 
> The really most frequent scenario is... they don't have such strict
> requirements and Ubercart + Drupal may be your best bet.
> 
> -- 
> Ivan Sergio Borgonovo
> http://www.webthatworks.it
>