On 3/1/07, Michael Radziej <[EMAIL PROTECTED]> wrote:
>
> Andy Dustman:
> > Here's another possible solution/workaround: MySQL supports an IGNORE
> > keyword on INSERT statements, which causes errors to be treated as
> > warnings.
> >
> > http://dev.mysql.com/doc/refman/5.0/en/insert.html
> >
> >
On Mar 2, 2007, at 12:50, mario__ wrote:
>
> On Feb 27, 8:31 pm, "Marc Fargas Esteve" <[EMAIL PROTECTED]> wrote:
>> -1 on option 1, and +1 in option 2. We should not remove
>> functionality because MySQL can't deal with that, simply document
>> "this won't work with mysql" :)
>>
>
> +1
Great
On Feb 27, 8:31 pm, "Marc Fargas Esteve" <[EMAIL PROTECTED]> wrote:
> -1 on option 1, and +1 in option 2. We should not remove
> functionality because MySQL can't deal with that, simply document
> "this won't work with mysql" :)
>
+1
Regards!
--~--~-~--~~~---~
Andy Dustman:
> Here's another possible solution/workaround: MySQL supports an IGNORE
> keyword on INSERT statements, which causes errors to be treated as
> warnings.
>
> http://dev.mysql.com/doc/refman/5.0/en/insert.html
>
> Not sure how hard it would be to incorporate this for this particular
Here's another possible solution/workaround: MySQL supports an IGNORE
keyword on INSERT statements, which causes errors to be treated as
warnings.
http://dev.mysql.com/doc/refman/5.0/en/insert.html
Not sure how hard it would be to incorporate this for this particular
case, though.
--
Patriotism
Hi,
On 2/27/07, Geert Vanderkelen <[EMAIL PROTECTED]> wrote:
> Because the other Databases have 'limitations' or 'features' or
> 'defects' that MySQL might not have or whatever. Django is, as I have
> been told, database independent. And Django is working fine with
> MySQL, lets keep it that way.
Jacob Kaplan-Moss wrote:
> Right now #2333 is all that 0.96 is waiting on
Please don't forget #1984. Thank you.
--
Nicola Larosa - http://www.tekNico.net/
When talking about Security, most people think about something where
"they" attack and "we" defend. If they succeed only once, we have los
On 2/28/07, Geert Vanderkelen <[EMAIL PROTECTED]> wrote:
>
> Django is, as I have
> been told, database independent. And Django is working fine with
> MySQL, lets keep it that way.
Well, no, MySQL isn't working fine. Like I said, [4610] didn't break
MySQL - it just revealed a problem that has alw
On Feb 27, 6:38 pm, "Ramiro Morales" <[EMAIL PROTECTED]> wrote:
> On 2/27/07, Geert Vanderkelen <[EMAIL PROTECTED]> wrote:
>
>
>
> > Because the other Databases have 'limitations' or 'features' or
> > 'defects' that MySQL might not have or whatever. Django is, as I have
> > been told, database ind
On 2/27/07, Geert Vanderkelen <[EMAIL PROTECTED]> wrote:
>
> Because the other Databases have 'limitations' or 'features' or
> 'defects' that MySQL might not have or whatever. Django is, as I have
> been told, database independent. And Django is working fine with
> MySQL, lets keep it that way.
A
On 2/27/07, Russell Keith-Magee <[EMAIL PROTECTED]> wrote:
[on reverting [4610]]:
> I'm -1 on this. Serialization and fixtures are near useless if you
> can't do forward references. [4610] introduces a test for forward
> references, and fixes a problem with Postgres. [4610] doesn't
> introduce an
Hi,
On 2/28/07, Russell Keith-Magee <[EMAIL PROTECTED]> wrote:
[...]
> Either way, the problem/limitations
> with MySQL needs to be mentioned in the documentation (both
> serialization and fixtures).
Yes, in really big red letters, we could add a directive for the
documentation rst for "thinks y
On 2/28/07, Jacob Kaplan-Moss <[EMAIL PROTECTED]> wrote:
>
> On 2/27/07, Seattle Daniel <[EMAIL PROTECTED]> wrote:
> > As I read it, there is not a way to force InnoDB to check constraints
> > at commit. And once there is it will be quite some time before the
> > mass of MySQL instances support it
On 27 Feb 2007, at 19:59, Sandro Dentella wrote:
..
>>
>> 1. Revert [4610] so that all databases work the same way, and not
>> allow forward references in serializers (or elsewhere).
>>
>> 2. Leave [4610] in, and not allow forward references in MySQL.
>>
>> I'd suggest #1 for orthogonality, but d
On Tue, Feb 27, 2007 at 11:26:11AM -0600, Jacob Kaplan-Moss wrote:
>
> On 2/27/07, Seattle Daniel <[EMAIL PROTECTED]> wrote:
> > As I read it, there is not a way to force InnoDB to check constraints
> > at commit. And once there is it will be quite some time before the
> > mass of MySQL instances
On 2/27/07, Seattle Daniel <[EMAIL PROTECTED]> wrote:
> As I read it, there is not a way to force InnoDB to check constraints
> at commit. And once there is it will be quite some time before the
> mass of MySQL instances support it.
So... I think that leaves is with two kinda sucky choices:
1. R
>From the MySQL docs:
Deviation from SQL standards: Like MySQL in general, in an SQL
statement that inserts, deletes, or updates many rows, InnoDB checks
UNIQUE and FOREIGN KEY constraints row-by-row. According to the SQL
standard, the default behavior should be deferred checking. That is,
constr
Hi Russell,
On 27 Feb 2007, at 16:16, Russell Keith-Magee wrote:
..
> Postgres has similar behaviour to InnoDB by default, but [4610]
> modified the table declarations to disable constraint checking until
> the end of a transaction using DEFFERABLE INITIALLY DEFERRED. However,
> apparently MySQL
Hi all,
Adrian has finally had a chance to look at, and approve the acceptance
of, the test fixtures patch. I sat down tonight to check in the patch,
did a last little check, and hit a snag - the trunk model tests break
under MySQL. Personally, I'm a Postgres jockey, so I need some
guidance from
19 matches
Mail list logo
