Apologies, I've been very distracted.
Adam K
On Fri, Nov 13, 2009 at 9:23 AM, Darren Duncan wrote:
> Adam Kennedy wrote on Nov 3:
>>
>> Righto, so I'm going to roll an official "release candidate" dev
>> version now, and we code freeze at this point (just docs and test
>> tweaks allowed between
Adam Kennedy wrote on Nov 3:
Righto, so I'm going to roll an official "release candidate" dev
version now, and we code freeze at this point (just docs and test
tweaks allowed between now and final).
I'll let the last dev release cook for 3 or 4 days, then do the prod one.
Adam, when were you p
It seems that Christmas came early this month. SQLite 3.6.20 was released 2
hours ago, and I committed it into the repository. And so the "last dev
release" 1.26_07 can include that, and prod can have it 3-4 days later as you
say. -- Darren Duncan
Adam Kennedy wrote:
Righto, so I'm going to
Righto, so I'm going to roll an official "release candidate" dev
version now, and we code freeze at this point (just docs and test
tweaks allowed between now and final).
I'll let the last dev release cook for 3 or 4 days, then do the prod one.
Adam K
2009/11/4 Kenichi Ishigaki :
> OK. Agreed.
>
OK. Agreed.
Kenichi
On Tue, 03 Nov 2009 21:28:59 -0800, Darren Duncan
wrote:
>Kenichi Ishigaki wrote:
>> Our tests are hardly thorough and complete, and while I tried
>> to write a test for foreign keys, I was hit by a weird bug
>> that suggested the internal sqlite3 object and the DBI/DBD::SQ
It didn't conform because it wasn't enforced and clearly a bug snuck
in there somewhere.
Since it happened in a giant 60,000 row CREATE TABLE FROM SELECT
statement, debugging the why will take me quite a while.
Adam K
2009/11/4 Darren Duncan :
> Adam Kennedy wrote:
>>
>> I really want to see at
Kenichi Ishigaki wrote:
Our tests are hardly thorough and complete, and while I tried
to write a test for foreign keys, I was hit by a weird bug
that suggested the internal sqlite3 object and the DBI/DBD::SQLite
handle objects were holding different statuses; the same statement
works fine when is
Our tests are hardly thorough and complete, and while I tried
to write a test for foreign keys, I was hit by a weird bug
that suggested the internal sqlite3 object and the DBI/DBD::SQLite
handle objects were holding different statuses; the same statement
works fine when issued one by one with do, a
Adam Kennedy wrote:
I really want to see at least one release where it's optional, so
there's a window of time for people to do optional upgrading, rather
than immediately forcing everything to fail.
I support your proposal, so go ahead as far as I'm concerned. Make a
1.27-stable release now
Adam Kennedy wrote:
The fact support is still light is all the more reason to get optional
support out there in wide distribution, so more than just this mailing
list have a chance to test it thoroughly.
At the moment, we're holding up this testing to just the people
willing to play with potenti
The fact support is still light is all the more reason to get optional
support out there in wide distribution, so more than just this mailing
list have a chance to test it thoroughly.
At the moment, we're holding up this testing to just the people
willing to play with potentially unstable releases
The foreign key support has already broken code of mine, I was using
the SQLite foreign key constraint syntax, so that ORM code generators
could detect the table relationships and generate various methods.
I really want to see at least one release where it's optional, so
there's a window of time f
>-Message d'origine-
>De : Dami Laurent (PJ) [mailto:laurent.d...@justice.ge.ch]
>Envoyé : mardi, 3. novembre 2009 08:31
>Anyway it's not specific to DBD-SQLite, because the same
>question must be asked for plain SQLite applications. Was it
>ever mentioned in the Sqlite mailing list
>-Message d'origine-
>De : Darren Duncan [mailto:dar...@darrenduncan.net]
>Envoyé : mardi, 3. novembre 2009 01:53
>
>2. Having foreign keys enabled by default would only affect
>people that are
>explicitly writing foreign key constraints into their SQL. So
>in general, why
>would
Then let's wait for another month and another sqlite release.
Releasing just before this Christmas would make more sense.
In the end, the current sqlite is the first version with
foreign keys support. They are doing pubic tests right now,
and we haven't seen, and will see the result probably in a
m
Adam Kennedy wrote:
For the first production release of DBD::SQLite with foreign keys,
it's starting to make me nervous that we will enable it by default.
As things currently stand, nobody that is using SQLite has ever seen
this feature before. They haven't had the chance to work with it at
all
For the first production release of DBD::SQLite with foreign keys,
it's starting to make me nervous that we will enable it by default.
As things currently stand, nobody that is using SQLite has ever seen
this feature before. They haven't had the chance to work with it at
all before we shove it dow
17 matches
Mail list logo
