Am 12.03.2012 12:40, schrieb Kit:
2012/3/12, Christoph P.U. Kukuliesk...@kukulies.org:
INSERT OR IGNORE INTO resource ...
INSERT OR REPLACE INTO instance ...
Thanks a lot. What is the idea behind the INSERT OR REPLACE in your
solution?
Christoph
If you edit a test for some version of your
Am 10.03.2012 09:06, schrieb Kit:
2012/3/9 Christoph P.U. Kukuliesk...@kukulies.org:
CREATE TABLE instance (
path TEXT,
basename TEXT,
size INT,
md5sum TEXT,
creation_date TEXT,
last_write_time TEXT,
FOREIGN KEY (md5sum)
2012/3/12, Christoph P.U. Kukulies k...@kukulies.org:
INSERT OR IGNORE INTO resource ...
INSERT OR REPLACE INTO instance ...
Thanks a lot. What is the idea behind the INSERT OR REPLACE in your
solution?
Christoph
If you edit a test for some version of your software, md5sum is
changed too.
Here's again the schema:
CREATE TABLE instance (
path TEXT,
basename TEXT,
size INT,
md5sum TEXT,
creation_date TEXT,
last_write_time TEXT,
FOREIGN KEY (md5sum) REFERENCES resource (md5sum)
);
CREATE TABLE
2012/3/12 Christoph P.U. Kukulies k...@kukulies.org:
Wouldn't the second and the third run result in being the records just
replaced (since they have the
same data in all columns and I don't have any uniqueness defined).
But instead I have three identical entries from each run.
Christoph
I
2012/3/9 Christoph P.U. Kukulies k...@kukulies.org:
CREATE TABLE instance (
path TEXT,
basename TEXT,
size INT,
md5sum TEXT,
creation_date TEXT,
last_write_time TEXT,
FOREIGN KEY (md5sum) REFERENCES resource (md5sum)
);
Am 04.03.2012 15:22, schrieb Kit:
2012/3/4 Christoph P.U. Kukuliesk...@kukulies.org:
CREATE TABLE dir(filename text, md5sum text, size int, content blob,
PRIMARY KEY(filename,md5sum,size));
Coming back to your suggestion using PRIMARY KEY(filename,md5sum,size), how
would I address this
Am 03.03.2012 19:29, schrieb Kit:
2012/3/3 Christoph P.U. Kukuliesk...@kukulies.org:
I'm building a unique ID made up from the basename, md5sum and
size of the file. This results
as a TEXT PRIMARY KEY (e.g. filename_md5sum_size).
Can I use (I'm using System.Data.SQLite) a try clause to find out
2012/3/4 Christoph P.U. Kukulies k...@kukulies.org:
Thanks for the ideas. The problem is with md5sum clashes: all files with 0
bytes have the same md5sum.
Also files with same contents have the same md5sum but may have a different
name.
That's no problem. if you put names to another table,
Am 04.03.2012 10:31, schrieb Kit:
2012/3/4 Christoph P.U. Kukuliesk...@kukulies.org:
Thanks for the ideas. The problem is with md5sum clashes: all files with 0
bytes have the same md5sum.
Also files with same contents have the same md5sum but may have a different
name.
That's no problem. if
2012/3/4 Christoph P.U. Kukulies k...@kukulies.org:
At the moment I have everything in the filesystem. The test situation is
that about 500 testprograms have to be run
with product release N against product release N-1. The test programs are
duplicated at the moment in all
places. The
Am 04.03.2012 10:31, schrieb Kit:
2012/3/4 Christoph P.U. Kukuliesk...@kukulies.org:
Thanks for the ideas. The problem is with md5sum clashes: all files with 0
bytes have the same md5sum.
Also files with same contents have the same md5sum but may have a different
name.
That's no problem. if
2012/3/4 Christoph P.U. Kukulies k...@kukulies.org:
CREATE TABLE dir(filename text, md5sum text, size int, content blob,
PRIMARY KEY(filename,md5sum,size));
Coming back to your suggestion using PRIMARY KEY(filename,md5sum,size), how
would I address this PRIMARY KEY, example:
I'm building
Am 02.03.2012 13:59, schrieb Jay A. Kreibich:
On Fri, Mar 02, 2012 at 10:44:20AM +0100, Christoph P.U. Kukulies scratched on
the wall:
When defining a column TEXT PRIMARY KEY (is that possible on TEXT?),
would this imply uniqueness?
Kind of. It implies uniqueness in the SQL sense, which
2012/3/3 Christoph P.U. Kukulies k...@kukulies.org:
I'm building a unique ID made up from the basename, md5sum and
size of the file. This results
as a TEXT PRIMARY KEY (e.g. filename_md5sum_size).
Can I use (I'm using System.Data.SQLite) a try clause to find out whether
the entry is already
When defining a column TEXT PRIMARY KEY (is that possible on TEXT?),
would this imply uniqueness?
Or would I have to write something like TEXT PRIMARY KEY UNIQUE ?
--
Christoph Kukulies
___
sqlite-users mailing list
sqlite-users@sqlite.org
On Fri, 02 Mar 2012 10:44:20 +0100, Christoph P.U. Kukulies
k...@kukulies.org wrote:
When defining a column TEXT PRIMARY KEY
(is that possible on TEXT?),
Yes that is possible on any data type.
would this imply uniqueness?
It would.
Or would I have to write something like TEXT PRIMARY
2012/3/2, Christoph P.U. Kukulies k...@kukulies.org:
When defining a column TEXT PRIMARY KEY (is that possible on TEXT?),
Yes.
would this imply uniqueness?
Yes.
Or would I have to write something like TEXT PRIMARY KEY UNIQUE ?
Christoph Kukulies
No. PRIMARY KEY is always UNIQUE.
--
Kit
Am 02.03.2012 10:44, schrieb Christoph P.U. Kukulies:
When defining a column TEXT PRIMARY KEY (is that possible on TEXT?),
yes
would this imply uniqueness?
yes
Or would I have to write something like TEXT PRIMARY KEY UNIQUE ?
no and that doesn't make sense I'd say
[...]
simply
Am 02.03.2012 11:03, schrieb Oliver Peters:
sorry I meant
CREATE TABLE test(
a TEXT PRIMARY KEY
);
(without INTEGER, usually I write INTEGER and not TEXT :-) )
Am 02.03.2012 10:44, schrieb Christoph P.U. Kukulies:
When defining a column TEXT PRIMARY KEY (is that possible on TEXT?),
yes
On Fri, Mar 02, 2012 at 10:44:20AM +0100, Christoph P.U. Kukulies scratched on
the wall:
When defining a column TEXT PRIMARY KEY (is that possible on TEXT?),
would this imply uniqueness?
Kind of. It implies uniqueness in the SQL sense, which does not
include NULLs (remember, NULL !=
02, 2012 4:13 AM
To: sqlite-users@sqlite.org
Subject: EXT :Re: [sqlite] TEXT PRIMARY KEY
Am 02.03.2012 11:03, schrieb Oliver Peters:
sorry I meant
CREATE TABLE test(
a TEXT PRIMARY KEY
);
(without INTEGER, usually I write INTEGER and not TEXT :-) )
Am 02.03.2012 10:44, schrieb Christoph P.U
On Fri, Mar 02, 2012 at 02:21:19PM +0100, Benoit Mortgat scratched on the wall:
On Fri, Mar 2, 2012 at 13:59, Jay A. Kreibich j...@kreibi.ch wrote:
On Fri, Mar 02, 2012 at 10:44:20AM +0100, Christoph P.U. Kukulies
scratched on the wall:
??Kind of. ??It implies uniqueness in the SQL sense,
23 matches
Mail list logo