I apologize for top posting and not snipping but a tablet makes that
difficult...
The problem with a db-specific function is that it makes a lot of otherwise
portable, driver-agnostic sql code not applicable to sqlite4. For example
PDO and similar abstraction layers.
On Jun 28, 2012 11:32 PM,
On Thu, Jun 28, 2012 at 4:32 PM, Simon Slavin wrote:
> I think SQLite4 will need to support AUTOINCREMENT for INTEGERs because so
> many SQL users will assume that it's supported.
Sure. At least for UNIQUE and PRIMARY KEY fields it's possible with
reasonable semantics.
On 28 Jun 2012, at 9:05pm, Nico Williams wrote:
> I think AUTOINCREMENT should imply that the column values a) must be
> INTEGER, b) tracking the max value seen so far. (b) is tricky because
> it's tempting to not require an index on that column unless it's
> constrained
From: sqlite-users-boun...@sqlite.org [sqlite-users-boun...@sqlite.org] on
behalf of Doug Currie [doug.cur...@gmail.com]
Sent: Thursday, June 28, 2012 3:15 PM
To: General Discussion of SQLite Database
Subject: EXT :Re: [sqlite] how to build sqlite4 (four)?
On Jun 28, 2012, at 4:05 PM, Nico
>> Too many SQLite3 apps assume a rowid. But I agree that not having a rowid
>> unless one is defined is the
>> correct thing to do.
Darn right they do. I'm relatively new to SQLite, but from what I've seen all
across the web, good use of the convenient rowed field is considered a best
On Jun 28, 2012, at 4:05 PM, Nico Williams wrote:
> It's also possibly a good idea to just not have autoincrement. Let
> the application implement it, no? After all, it can, including via
> triggers.
Or with PostgreSQL-style sequences
On Thu, Jun 28, 2012 at 2:48 PM, Richard Hipp wrote:
> Note that SQLite4 does not have a rowid (at last not always) so the whole
> concept of autoincrement will need to be revisited. I don't think the old
> SQLite3 way of doing autoincrement makes sense any more. Not good sense
On Thu, Jun 28, 2012 at 7:23 PM, Stephan Beal wrote:
> i'm racing to be the first to adapt his db access abstraction layer to
> sqlite4 and i've hit my first stumbling block...
>
i hope this qualifies as "first" ;)
On Thu, Jun 28, 2012 at 9:48 PM, Richard Hipp wrote:
> Note that SQLite4 does not have a rowid (at last not always) so the whole
> concept of autoincrement will need to be revisited. I don't think the old
> SQLite3 way of doing autoincrement makes sense any more. Not good
>
On Thu, Jun 28, 2012 at 3:22 PM, Stephan Beal wrote:
> A follow-up:
>
> i've got it linking now, but i am seeing different behaviour between
> autoincrement fields and sqliteX_last_insert_rowid(). v4 doesn't allow the
> following SQL:
>
Autoincrement isn't working yet. I
On Thu, Jun 28, 2012 at 9:22 PM, Stephan Beal wrote:
> i haven't yet narrowed down the problem, but wanted to point it out. If
> it's a known problem, let me know and i'll stop digging.
>
A couple more details:
schema:
CREATE TABLE t(
vInt INTEGER NOT NULL PRIMARY KEY
A follow-up:
i've got it linking now, but i am seeing different behaviour between
autoincrement fields and sqliteX_last_insert_rowid(). v4 doesn't allow the
following SQL:
and when i hard-code a row ID into my test SQL it's last_insert_rowid() is
returning <=0 (i don't yet know which - an
On Thu, Jun 28, 2012 at 8:35 PM, Stephan Beal wrote:
> http://localhost:8080/artifact/3a695fc9bb272a4f5ca0d1a8cf540d61b52ff534
>
> (i strongly suspect that link will work for you ;)
>
> contains Table::tnum.
>
That's a lie - tnum is in Index in that version.
--
-
On Thu, Jun 28, 2012 at 8:25 PM, Richard Hipp wrote:
> My makefile uses gcc. Why don't you change yours to gcc too, to see if
> that helps.
>
Strangely enough, no. i can't quite explain this because i'm on trunk and:
My makefile uses gcc. Why don't you change yours to gcc too, to see if
that helps.
On Thu, Jun 28, 2012 at 2:14 PM, Stephan Beal wrote:
> On Thu, Jun 28, 2012 at 7:35 PM, Richard Hipp wrote:
>
> > My makefile has the following:
> >
>
> Thanks for the
On Thu, Jun 28, 2012 at 7:35 PM, Richard Hipp wrote:
> My makefile has the following:
>
Thanks for the tips. My initial problem was that sqlite4.h was 0 bytes due
to a failed build before i had installed tclsh and clang. That of course
caused grief. Removing it and rebuilding
On Thu, Jun 28, 2012 at 1:23 PM, Stephan Beal wrote:
> Hiho!
>
> i'm racing to be the first to adapt his db access abstraction layer to
> sqlite4 and i've hit my first stumbling block...
>
Everything is still pretty makefile-touchy. Remember, this is like
pre-alpha code.
On Thu, Jun 28, 2012 at 7:23 PM, Stephan Beal wrote:
> stephan@tiny:~/cvs/fossil/sqlite4$ make
> clang -g -o mkkeywordhash -DSQLITE_DEBUG=1 -DHAVE_GMTIME_R -
>
Sorry, should have added:
stephan@tiny:~/cvs/fossil/sqlite4$ clang --version
clang version 2.9
Hiho!
i'm racing to be the first to adapt his db access abstraction layer to
sqlite4 and i've hit my first stumbling block...
stephan@tiny:~/cvs/fossil/sqlite4$ make
clang -g -o mkkeywordhash -DSQLITE_DEBUG=1 -DHAVE_GMTIME_R
-DHAVE_LOCALTIME_R -DHAVE_MALLOC_USABLE_SIZE -DHAVE_USLEEP
19 matches
Mail list logo