Skip Menu |

This queue is for tickets about the Email-Store CPAN distribution.

Report information
The Basics
Id: 13092
Status: resolved
Priority: 0/
Queue: Email-Store
People
Owner: Nobody in particular
Requestors: nate [...] cs.wisc.edu
Cc:
AdminCc:
Bug Information
Severity: Critical
Broken in: 0.24
Fixed in: (no value)

History Show all quoted text
  Sat Jun 04 22:02:04 2005 Guest - Ticket created
Subject: Problem with autoincrement id fields and PostgreSQL
The MySQL schema for Email::Store::Attachment and Email::Store::Entity have autoincrement integer fields for "id". MySQL implements this is a highly non -standard way. For PostgreSQL this is translated to an integer field that defaults to the next value of a sequence (SQL03). Unfortunatly, when Class::DBI generates SQL it specifies a null id instead of leaving it out. This works for MySQL's autoincrement type, but fails when using a default value. This is yet another critical error for PostgreSQL and probably other databases as well. I'm not sure what a good solution is. It looks like the id field can just be dropped for the attachment table but the entity tables are trickier. I'll see if I can think of something and send in a patch. Either way, the autoincrement syntax is 100% non-portable. Either it or the advertised support for non-MySQL databases needs to be removed.
  Mon Jun 06 10:43:30 2005 simonw [...] cpan.org - Status changed from 'new' to 'open'
  Mon Jun 06 10:43:30 2005 simonw [...] cpan.org - Correspondence added
[guest - Sat Jun 4 22:02:04 2005]: Show quoted text
> Either way, the autoincrement syntax is 100% non-portable. Either it > or the advertised support for non-MySQL databases needs to be > removed.
Hmm, I'll ask the Class::DBI list about this - I'm pretty sure that I've had this working elsewhere.
  Sun Jul 23 08:15:14 2006 rjbs [...] cpan.org - Correspondence added
This was fixed in a later CDBI, which we now require. -- rjbs
  Sun Jul 23 08:15:15 2006 rjbs [...] cpan.org - Status changed from 'open' to 'resolved'