On Thu, 23 Nov 2017 17:35:08 -0700
"Keith Medcalf" escribió:
>
> That is correct. You cannot spell "INTEGER PRIMARY KEY", which is an
> explicit alias for the rowid, as anything other than that one particular
> correct spelling.
>
> Personally, I have never found a use for the AUTOINCREMENT
The one thing that saddens me is that the clock is not the full first
part of the UUID, so it's not a proxy for sorting by creation date. I
often wonder why they did that, they must have done it on purpose.
On 11/25/17, Peter Da Silva wrote:
>>> What about time resets to the epoch which are not r
>> What about time resets to the epoch which are not restored, user time
>> changes,
>
> I know some systems at least increment the node each time a time change is
> detected. It will take 2^47 time changes to roll over. Since the node part is
> not relevant to SQLite, this is perfectly safe.
Ah, I see someone else has already brought up version 1 UUIDs.
> What about invalid and reused MAC addresses and devices with no MAC address
> at all?
Not an issue with SQLite since that part of the UUID is a constant within a
given database. It would be reasonable to simply pick "0" then set t
Are people here talking about UUIDs or things that just look like UUIDs? It
sounds like the latter. UUIDs are actually structured objects, with embedded
type bits. There are multiple UUID generation schemes, one of which is based on
random numbers, others are based on hashes, and there is the co
What about invalid and reused MAC addresses and devices with no MAC address at
all?
What about time resets to the epoch which are not restored, user time changes,
daylight saving or leap seconds?
It sounds even more probabilistic than the probabilistic methods. Does anyone
actually use it?
>
J. King
>Sent: Friday, 24 November, 2017 20:54
>To: SQLite mailing list
>Subject: Re: [sqlite] "BIGINT" doesn't act like INTEGER on table
>creation [Bug]
>
>Version 1 UUIDs only use a random number (16 bits) in the case of an
>uninitialized clock sequence (a case w
Peter (that is, the other Peter) is being more than a little flippant, yes, and
at least a little obscure (I don't get the joke, either), but the substance
appears quite serious.
His prior message suggested using what I can only assume would be a trivial
extension to SQLite to do what you want
Is this a joke?
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Well, first you imagine you're back at the office in Santa Clara or Redmond
in the early 1990's.
Then take a belt of whisky, cross your eyes, and paste from doc to
clipboard a few edits and voila:
#include "sqlite3ext.h"
#include
SQLITE_EXTENSION_INIT1
static struct metadata {
char const *z
Version 1 UUIDs only use a random number (16 bits) in the case of an
uninitialized clock sequence (a case which, ideally, should only occur the
first time a device generates a UUID). Version 1 UUIDs especially avoid using
random numbers; they are also not a shortening of longer input.
In short
On 11/24/17 8:58 PM, Jean-Christophe Deschamps wrote:
At 23:49 24/11/2017, you wrote:
On 11/24/17 5:26 PM, Jean-Christophe Deschamps wrote:
At 22:38 24/11/2017, you wrote:
One proof of the falsehood of your assertion is that we CAN fill a
database with some data using UIDs, and we will almo
qlite-users [mailto:sqlite-users-
>boun...@mailinglists.sqlite.org] On Behalf Of Richard Damon
>Sent: Friday, 24 November, 2017 14:39
>To: sqlite-users@mailinglists.sqlite.org
>Subject: Re: [sqlite] "BIGINT" doesn't act like INTEGER on table
>creation [Bug]
&g
At 00:13 25/11/2017, you wrote:
Looks like I do need to use AUTOINCREMENT after all, otherwise the
framework I'm using doesn't appear to recognize that INTEGER PRIMARY KEY
columns are allowed a NULL value on insert.
I can't answer about just INTEGER PRIMARY KEY columns, but any table
with an
At 23:49 24/11/2017, you wrote:
On 11/24/17 5:26 PM, Jean-Christophe Deschamps wrote:
At 22:38 24/11/2017, you wrote:
One proof of the falsehood of your assertion is that we CAN fill a
database with some data using UIDs, and we will almost certainly not
get a collision, while you assertion
> sqlite> .load column-meta-data.so
Sorry I'm at a loss to find this extension? Google gives me nothing related
to SQLite for "isRowId", "column-meta-data.so", "column-meta-data.c", etc.
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
Apparently you would query pragma_table_info for "INTEGER" PK columns and
then ask through a trivial extension function about the other column
meta-data:
https://www.sqlite.org/c3ref/table_column_metadata.html
The basic plot is illustrated below:
sqlite> .load column-meta-data.so
sqlite> SELECT
On Fri, Nov 24, 2017 at 3:13 PM, Peter Halasz
wrote:
> Sorry to steer the conversation back to the topic.
>
> Looks like I do need to use AUTOINCREMENT after all, otherwise the
> framework I'm using doesn't appear to recognize that INTEGER PRIMARY KEY
> columns are allowed a NULL value on insert.
Sorry to steer the conversation back to the topic.
Looks like I do need to use AUTOINCREMENT after all, otherwise the
framework I'm using doesn't appear to recognize that INTEGER PRIMARY KEY
columns are allowed a NULL value on insert. That's a shame.
Is there a way to query a schema to get a dire
On Fri, Nov 24, 2017 at 11:25 AM, Keith Medcalf wrote:
>
> Actually a UUID or a GUID has a 100% certainty of a collision, not just a
> possibility of a collision. Just as all hash algorithms which take
> something and generate a shorter "hash" or "checksum" will always have
> collisions. Witho
On 11/24/17 5:26 PM, Jean-Christophe Deschamps wrote:
At 22:38 24/11/2017, you wrote:
One proof of the falsehood of your assertion is that we CAN fill a
database with some data using UIDs, and we will almost certainly not
get a collision, while you assertion we will.
This is an attempt at "p
At 22:38 24/11/2017, you wrote:
One proof of the falsehood of your assertion is that we CAN fill a
database with some data using UIDs, and we will almost certainly not
get a collision, while you assertion we will.
This is an attempt at "proof by example". Keith is perfectly right
--mathemati
On 11/24/17 2:25 PM, Keith Medcalf wrote:
Actually a UUID or a GUID has a 100% certainty of a collision, not just a possibility of a
collision. Just as all hash algorithms which take something and generate a shorter
"hash" or "checksum" will always have collisions. Without exception and as a
nticipated traffic volume.
>-Original Message-
>From: sqlite-users [mailto:sqlite-users-
>boun...@mailinglists.sqlite.org] On Behalf Of Stephen Chrzanowski
>Sent: Friday, 24 November, 2017 11:21
>To: SQLite mailing list
>Subject: Re: [sqlite] "BIGINT" doesn't ac
Message-
>From: sqlite-users [mailto:sqlite-users-
>boun...@mailinglists.sqlite.org] On Behalf Of Richard Damon
>Sent: Friday, 24 November, 2017 10:33
>To: sqlite-users@mailinglists.sqlite.org
>Subject: Re: [sqlite] "BIGINT" doesn't act like INTEGER on table
>
Obviously, this is a design time factor, but, in my applications, I always
use integer IDs if I'm ever going to bring the info that row contains (And
other relevant info) to the UI. I have never had a solid reason to use
GUIDs or UUIDs or whatever.
Any time I'm adding something to a listbox, comb
On 11/24/17 3:51 AM, R Smith wrote:
On 2017/11/24 5:23 AM, Peter Halasz wrote:
As for whether I need to use AUTOINCREMENT, it seemed like a good
idea to
avoid rowid reuse, but I can avoid using it for the sake of
optimization,
so probably will.
I agree with Keith and has many times mentione
On Fri, Nov 24, 2017 at 9:51 AM, R Smith wrote:
> I'm not even a big fan of Integer IDs, I think codes / UUIDs are best, but
> obviously the speed/size gain with an integer key (especially INTEGER
> PRIMARY KEY row-id alias in SQLite) can't be ignored.
>
> Disclaimer: This is only my opinion, wel
On 2017/11/24 5:23 AM, Peter Halasz wrote:
As for whether I need to use AUTOINCREMENT, it seemed like a good idea to
avoid rowid reuse, but I can avoid using it for the sake of optimization,
so probably will.
I agree with Keith and has many times mentioned this before (apologies
to others for
I just want to note here that I'm uncomfortable with the docs on type
affinity in a general sort of way. I've read that section several
times in the hope of feeling more comfortable, but so far I still
don't. Unfortunately I can't say how I would improve them exactly, I
just know they leave me wi
Thank you. It looks like I was looking at the wrong documentation page.
So I will reiterate and clarify my advice that the datatype documentation (
https://sqlite.org/datatype3.html), within the section on "Determination Of
Column Affinity", should more clearly state the fact that the affinity
rul
lite.org] On Behalf Of Peter Halasz
>Sent: Thursday, 23 November, 2017 17:14
>To: sqlite-users@mailinglists.sqlite.org
>Subject: [sqlite] "BIGINT" doesn't act like INTEGER on table creation
>[Bug]
>
>BIGINT has a "resulting affinity" of INTEGER (
>http
BIGINT has a "resulting affinity" of INTEGER (
https://sqlite.org/datatype3.html) but cannot be used in its place in the
following example:
CREATE TABLE [FailTable] ( [id] BigInt PRIMARY KEY AUTOINCREMENT )
...as it gives this error:
AUTOINCREMENT is only allowed on an INTEGER PRIMARY KE
33 matches
Mail list logo
