search

TrogloGeek / prestashop-tggatos-module

TggAtos Module for Prestashop (1.4 to 1.7), ATOS SIPS 6xx payment gateway
61 stars 34 forks source link

ps_tggatos_transactions_today InnoDB #17

Closed pppplus closed 10 years ago

pppplus commented 10 years ago

Hi

The table ps_tggatos_transactions_today can't be change to InnoDB as other tables. It's because of Incremental Field, which has to be Primary key

And primary key is date + transaction_id

TrogloGeek commented 10 years ago

Yes, indeed, this is why MyISAM engine is forced on table creation. So, what is the problem ?

pppplus commented 10 years ago

Hi, just a problem of logic. If I have all my tables in InnoDB, it's not logical to have one in MyIsam.

So, not a real problem, just not logical.

TrogloGeek commented 10 years ago

I disagree about the logical issue : each data storage engine has been designed to achieve goals, each has pros and cons, key features and unavailable features, enhanced performances in some use cases, performance holes in others.

Each data storage table in an application has also some goals to achieve. Some table belong to a relational scheme and perform better if they have foreign keys, some don't. Some will handle massive write access and a few reads, some will handle the opposite, some will handle a balanced mix of reads and writes...

transactions_today table purpose is to provide a thread safe day based counter, and MyISAM is great to achieve this under heavy load while being available for the many. This module is a project I actually fund myself at about 70%, others 30% are donations and paid support or installation I provide. The goal is to provide a stable Prestashop/Atos-Sips gateway suitable for the largest use spectrum I can provide. Doing so with a InnoDB table would require a large rewrite of daily counter management, I'm not event sure I could provide an equally reliable daily counter in multi-threaded environment using an InnoDB table. One of the reasons I initiated this project is because I've never found any SIPS gateway able to provide a highly reliable transaction ID generator keeping ID waste as low as possible to provide to the clients of the agency I work for. It turned out that the only use this module once, to replace another module we used after heavy corrections but which had been designed for low life cycle which bugged me, and we only use a really low feature set of the module. This project's maintenance costs me alot of unpaid time (for exemple, this answers required me more than one hour of my time), but hey, it's kind of a hobby to try to maintain a high quality piece of software, and I want to keep costs participation on a willing basis. This MyISAM table is the keystone of this module's reliability, you'll have to provide better arguments to even make me think about changing it.

That being said, if you really don't want a MyISAM table to maintain, you can use the module with disabled transaction ID generator, in which case it relies on SIPS generator, which just uses you server time to generate it with a hhmmss time mask; which is known to waste alot ID's and cause ID collisions on multi-threaded environnement => a nice error page on bank server if the ID has already been used today (even for an aborted transaction), only suitable to low traffic shop were you NEVER have two clients which use the same payment gateway at the same second.

TrogloGeek commented 10 years ago

Due to the lack of response offering counter arguments, this issue is closed.