A new version of the plugin has been released thanks to Andrew Donkin
who provided a variety of updates for the code. The updates include the
following changes -
- Removed the exists sub as it is not necessary when using an INSERT
with ON DUPLICATE KEY UPDATE.
- Removed the TOTALS insert
I am running MySQL 5.0 and WAS receiving an error for the SQL
statement that had the 'ON DUPLICATE KEY UPDATE'. After doing a little
investigation and looking into the MySQL docs I have fixed the issue.
I dropped the entire WHERE from the statement. According to MySQL
docs, there
You did have the latest version Duane.
I guess MySQL 4.1 doesn't care if you have the WHERE clause after it;
as I have been using the updated version for sometime and have not
received any errors. But MySQL 5.0, apparently, doesn't like that
syntax. I removed the WHERE clause and tested it
On Monday, January 2, 2006 at 6:50:15 PM, [EMAIL PROTECTED] confabulated:
You did have the latest version Duane.
I guess MySQL 4.1 doesn't care if you have the WHERE clause after it;
as I have been using the updated version for sometime and have not
received any errors. But MySQL 5.0,
I have updated the INSERT code to use the ON DUPLICATE KEY feature of
MySQL. This feature insures that if the insert statement is executed
and another insert has already occurred for the changing day, an update
will take place instead. Hopefully, this will alleviate the largest
possibility of a
James Keating wrote:
Well the simplest fix is the one that I did not implement in the first
place, using ON DUPLICATE KEY. However, I did not implement that
because of its only being in version 4.1 of MySQL and I still use
Debian stable for most production machines, which runs 4.0.x.
On Wed, Dec 28, 2005 at 02:19:51AM -0600, Chris Thielen wrote:
James Keating wrote:
Well the simplest fix is the one that I did not implement in the first
place, using ON DUPLICATE KEY. However, I did not implement that
because of its only being in version 4.1 of MySQL and I still use
[OT] FYI, both 4.0 and 4.1 are available in Debian stable.
do you know, which (maybe) problems by change of MySQL 4.1
becomes? Or not? I mean database errors and so on. I`ve heard of
password and charset mistakes.
--
Viele Grüße, Kind regards,
Jim Knuth
Sorry Jim, I have not tried an
Heute (28.12.2005/19:45 Uhr) schrieb Gary V ([EMAIL PROTECTED]),
[OT] FYI, both 4.0 and 4.1 are available in Debian stable.
do you know, which (maybe) problems by change of MySQL 4.1
becomes? Or not? I mean database errors and so on. I`ve heard of
password and charset mistakes.
--
Viele
Neat plugin. I have two comments:
I wouldn't store $TOTALS or the total column in the database, as both
can easily be calculated when retrieving the data.
There is a race condition, especially for $TOTALS. First you check for
existence, then you try and do an insert or an update based on that.
Indeed. My thinking behind storing both system totals ($TOTALS) and user
totals in the database was for easy error checking. Each day you can
quickly/easily run through the database and look for potential errors
(possibly resulting from the race condition that you mentioned).
However, I have
On Tue, Dec 27, 2005 at 09:33:11PM -0500, James Keating wrote:
Indeed. My thinking behind storing both system totals ($TOTALS) and user
totals in the database was for easy error checking. Each day you can
quickly/easily run through the database and look for potential errors
(possibly
Well the simplest fix is the one that I did not implement in the first
place, using ON DUPLICATE KEY. However, I did not implement that
because of its only being in version 4.1 of MySQL and I still use Debian
stable for most production machines, which runs 4.0.x.
Anyway, I will poke at it
Well the simplest fix is the one that I did not implement in the first
place, using ON DUPLICATE KEY. However, I did not implement that because
of its only being in version 4.1 of MySQL and I still use Debian stable for
most production machines, which runs 4.0.x.
Anyway, I will poke at it
Heute (28.12.2005/05:41 Uhr) schrieb Gary V ([EMAIL PROTECTED]),
Well the simplest fix is the one that I did not implement in the first
place, using ON DUPLICATE KEY. However, I did not implement that because
of its only being in version 4.1 of MySQL and I still use Debian stable for
most
Gary V wrote:
Well the simplest fix is the one that I did not implement in the first
place, using ON DUPLICATE KEY. However, I did not implement that
because of its only being in version 4.1 of MySQL and I still use
Debian stable for most production machines, which runs 4.0.x.
Anyway, I
Morning All,
I have released a real-time stats collection plugin
(http://wiki.apache.org/spamassassin/StatsPlugin)for SpamAssassin.
The plugin collects data into a MySQL DB based on the date and username
that SpamAssassin was invoked with. This creates a single row for each
user, each
17 matches
Mail list logo
