Re: [sqlite] Article: UUID or GUID as Primary Keys? Be Careful!

[Daniel Anderson]

I drink to that!

2017-06-10 14:26 GMT-04:00 Jens Alfke <j...@mooseyard.com>:

>
> > On Jun 10, 2017, at 6:58 AM, Daniel Anderson <woni...@gmail.com> wrote:
> >
> > the article was integers (4 bytes) vs guid as a primary key, which as
> > string takes 36 bytes. so he was right in saying that string guid/uuid
> take
> > 9 time the space of simple integers.
>
> Ah, that explains where he got 9x. I still think it’s an unfair
> comparison, given the inefficient encoding of the UUID (it should be a
> 16-byte blob.) And in any design problem that’s at sufficient scale that
> you’re even considering UUIDs, a 32-bit primary key isn’t going to be
> sufficient, so it should be 64-bit. Now we’re down to a 2x difference.
>
> > in general the article was quite good and allowed people to ponder about
> > their choices/beliefs.
>
> I would have been less critical, had the author identified that the
> subject domain is traditional RDBMSs. Instead the implication is that this
> is relevant to any database, which it isn’t.
>
> Anyway, arguing about databases is boring. It’s the weekend — I’m off to
> play guitar and go to parties ;-)
>
> —Jens
> ___
> sqlite-users mailing list
> sqlite-users@mailinglists.sqlite.org
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
>



-- 
Daniel
*L'action accède à la perfection quand, bien que vivant, vous êtes déjà
mort*
*Bunan*
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Article: UUID or GUID as Primary Keys? Be Careful!

[Daniel Anderson]

the article was integers (4 bytes) vs guid as a primary key, which as
string takes 36 bytes. so he was right in saying that string guid/uuid take
9 time the space of simple integers.

in general the article was quite good and allowed people to ponder about
their choices/beliefs.

he said be: *careful*, which is a good rule of thumb, as design decisions
are often cast in stone and cannot be change because to many external
programs depends on them.


regards


2017-06-10 8:13 GMT-04:00 R Smith :

>
> On 2017/06/10 6:27 AM, Jens Alfke wrote:
>
>> On Jun 9, 2017, at 3:05 PM, Simon Slavin  wrote:
>>>
>>> Tangential to SQLite, but there’s little on the list at the moment so
>>> perhaps some of you might like this.
>>> >> careful-7b2aa3dcb439 >> d-or-guid-as-primary-keys-be-careful-7b2aa3dcb439>>
>>>
>> He makes some questionable points, like saying that an ASCII string of
>> hex has a “9x cost in size” compared to a binary representation, or that
>> hex strings would somehow get larger when converted from ISO-8859-1 to
>> UTF-8.
>>
>
> Just in case people wonder about your assertion that his assertion is
> wrong - to be specific: UTF8 consumes the exact same space as ASCII when
> you use only characters from the first block (0..7F) - which is exactly
> what a UUID uses, at a maximum characters 0..9, A..F or a..f, -, {, and }.
> Nothing outside of the first Unicode block - though it should be noted that
> some systems may use Double-byte (16 bit) character representations
> internally whenever the DB table text *storage* type is set to UTF-anything
> (which should be noted is not the same thing as the *DB-Interface* type
> being UTF-anything).
>
> So the blogger's point doesn't hold on that assertion.
>
> Further, a UUID/GUID as per the standard (RFC4122) consists of 128 bit
> value formatted to present like this 36-character sequence:
> --Axxx-Bxxx-
>
> where A is a variant and B is the version of the UUID represented.
> Variants define different methods of calculation, like whether the MAC
> address with a time component was used, or a Domain/Namespace based UUID
> etc. In DB systems we usually use variant 1 (MAC+Time with 100 nanosecond
> precision) which, unless mechanical failure or intentional deceit, must be
> unique (i.e. probability for global collision = 0 if created exactly as
> described and all systems work as designed, and some cosmic ray doesn't hit
> your processor just right [or is it just wrong?]).
>
> Anyway, about the layout, you can of course simply store the UUID as a 128
> bit value (or 2 64-bit INTs - considering you use the exact same variant
> and version for all your IDs, but this takes processing and you end up with
> a value that needs to be re-computed before it can be compared to anything
> outside of your system), or at a minimum remove any dashes and braces, but
> in reality most people will just plop it as-is into a Text/Varchar field
> that's been Uniqued and probably PK'd.
>
> In that worst case scenario (all of the UUID plus dashes and braces), the
> full storage requirement for a UUID would look like this:
> {--Axxx-Bxxx-} which totals 38 characters of
> ASCII (or UTF-8) text space which totals 38 bytes.
> Let's be generous and assume the user made VARCHAR(40) provision on an
> old-style DB which reserves all the bytes, or better yet, a modern one with
> a length definition that takes a further 32-bit value, so 42 bytes then.
> Even in this very worst case scenario, the full space requirement for a
> UUID is a dismal ~2.7 times more than the 16 bytes of space the original
> 128-bit value consumed. Let's further assume the worst text storage system
> using DBCS to store 16 bits per character (and nobody really does this),
> even then we only get to just over 5 times. Where did he get 9 times from??
> The typical usage, storing full text UUID minus braces in an ASCII/UTF-8
> sequence will result in a hair over 2.3 times[1] the storage of INTs. Not
> really that bad I think.
>
> I find it fascinating that the number 1 reason to not use UUIDs, and
> probably the only reason, he never even mentioned. Sheer speed. (He refers
> sorting speed, but the real gain is look-up speed, which gets compounded in
> a compound query). In MSSQL I measured almost double the lookup speed using
> INTs in a PK in stead of VARCHARs (I didn't even use UUIDs, simply
> 6-character client codes of the form ABC001 etc.).
>
> Where I DO agree with the blogger: Where space is not a big concern, use
> both UUIDs and INTs locally in your DB, that way it is always scalable,
> always merge-able with other global data and always fast with the right
> query.
>
> Cheers,
> Ryan
>
> [1] - It's hard to say exactly, most DBs use extra bits/bytes for field
> specifications, lengths etc, even for the INT fields, so making an exact
> 

Re: [sqlite] Create database

[Daniel Anderson]

http://lmgtfy.com/?q=sqlite+c%2B%2B+wrapper

2017-04-15 0:05 GMT-04:00 Keith Medcalf <kmedc...@dessus.com>:

>
> What existing one?  SQLite3 is written in C ...
>
> --
> ˙uʍop-ǝpısdn sı ɹoʇıuoɯ ɹnoʎ 'sıɥʇ pɐǝɹ uɐɔ noʎ ɟı
>
> > -Original Message-
> > From: sqlite-users [mailto:sqlite-users-boun...@mailinglists.sqlite.org]
> > On Behalf Of Daniel Anderson
> > Sent: Friday, 14 April, 2017 21:11
> > To: SQLite mailing list
> > Subject: Re: [sqlite] Create database
> >
> > you would probably be better off using C++ to handle everything, less
> > chances of forgetting to close something.
> >
> > do not build your own classes, use existing one!
> >
> > 2017-04-14 10:44 GMT-04:00 Igor Korot <ikoro...@gmail.com>:
> >
> > > Keith,
> > >
> > > On Fri, Apr 14, 2017 at 10:37 AM, Keith Medcalf <kmedc...@dessus.com>
> > > wrote:
> > > >
> > > > To further clarify, the result of doing multiple sqlite3_open calls
> > and
> > > saving the results to the save db handle is the same as doing
> > > >
> > > > fh = fopen(...)
> > > > fh = fopen(...)
> > > > fh = fopen(...)
> > > >
> > > > You have opened multiple files but are only keeping track of 1.  So
> > > although three files are opened fclose(fh) will only close the last
> one,
> > > and the first two are still open, you just discarded your reference to
> > them
> > > and they are inaccessible to you.
> > > >
> > > > If you do this sort of thing a lot then you program will eventually
> > > crash when it fills up with unreferenced (leaked) memory objects that
> > you
> > > forgot (and have overwritten the handle) to close.
> > >
> > > Thank you for clarifying.
> > > It means that the call to sqlite3_open() does not close previously
> > > opened database and I have to explicitly close it
> > > with sqlite3_close().
> > >
> > > I was just couldn't find it anywhere in the docs. Probably missed it.
> > >
> > > >
> > > > --
> > > > ˙uʍop-ǝpısdn sı ɹoʇıuoɯ ɹnoʎ 'sıɥʇ pɐǝɹ uɐɔ noʎ ɟı
> > > >
> > > >
> > > >> -Original Message-
> > > >> From: sqlite-users [mailto:sqlite-users-
> > boun...@mailinglists.sqlite.org
> > > ]
> > > >> On Behalf Of Keith Medcalf
> > > >> Sent: Friday, 14 April, 2017 08:32
> > > >> To: SQLite mailing list
> > > >> Subject: Re: [sqlite] Create database
> > > >>
> > > >>
> > > >> No, a new database will be opened and you will be given an sqlite3*
> > to
> > > it.
> > > >>
> > > >> Just like the fopen() call can be used to open multiple files,
> > > >> sqlite3_open* opens a database.  The way to close an sqlite3*
> (handle
> > to
> > > >> a) database is to use sqlite3_close specifying the database you want
> > to
> > > >> close.
> > > >>
> > > >> --
> > > >> ˙uʍop-ǝpısdn sı ɹoʇıuoɯ ɹnoʎ 'sıɥʇ pɐǝɹ uɐɔ noʎ ɟı
> > > >>
> > > >>
> > > >> > -Original Message-
> > > >> > From: sqlite-users [mailto:sqlite-users-bounces@
> > > mailinglists.sqlite.org]
> > > >> > On Behalf Of Igor Korot
> > > >> > Sent: Friday, 14 April, 2017 08:26
> > > >> > To: Discussion of SQLite Database; General Discussion of SQLite
> > > Database
> > > >> > Subject: [sqlite] Create database
> > > >> >
> > > >> >  Hi,
> > > >> > If I have a database open with sqlite3_open() and then want to
> > issue
> > > >> > another sqlite3_open(),
> > > >> > the old database will be closed and the new one will open?
> > > >> > Or I have to explicitly call sqlite3_close()?
> > > >> >
> > > >> > Thank you.
> > > >> > ___
> > > >> > sqlite-users mailing list
> > > >> > sqlite-users@mailinglists.sqlite.org
> > > >> > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-
> > users
> > > >>
> > > >>
> > > >>
> > > >> ___
> > > >> sqlite-users mailing list
> > > >

Re: [sqlite] Create database

[Daniel Anderson]

you would probably be better off using C++ to handle everything, less
chances of forgetting to close something.

do not build your own classes, use existing one!

2017-04-14 10:44 GMT-04:00 Igor Korot :

> Keith,
>
> On Fri, Apr 14, 2017 at 10:37 AM, Keith Medcalf 
> wrote:
> >
> > To further clarify, the result of doing multiple sqlite3_open calls and
> saving the results to the save db handle is the same as doing
> >
> > fh = fopen(...)
> > fh = fopen(...)
> > fh = fopen(...)
> >
> > You have opened multiple files but are only keeping track of 1.  So
> although three files are opened fclose(fh) will only close the last one,
> and the first two are still open, you just discarded your reference to them
> and they are inaccessible to you.
> >
> > If you do this sort of thing a lot then you program will eventually
> crash when it fills up with unreferenced (leaked) memory objects that you
> forgot (and have overwritten the handle) to close.
>
> Thank you for clarifying.
> It means that the call to sqlite3_open() does not close previously
> opened database and I have to explicitly close it
> with sqlite3_close().
>
> I was just couldn't find it anywhere in the docs. Probably missed it.
>
> >
> > --
> > ˙uʍop-ǝpısdn sı ɹoʇıuoɯ ɹnoʎ 'sıɥʇ pɐǝɹ uɐɔ noʎ ɟı
> >
> >
> >> -Original Message-
> >> From: sqlite-users [mailto:sqlite-users-boun...@mailinglists.sqlite.org
> ]
> >> On Behalf Of Keith Medcalf
> >> Sent: Friday, 14 April, 2017 08:32
> >> To: SQLite mailing list
> >> Subject: Re: [sqlite] Create database
> >>
> >>
> >> No, a new database will be opened and you will be given an sqlite3* to
> it.
> >>
> >> Just like the fopen() call can be used to open multiple files,
> >> sqlite3_open* opens a database.  The way to close an sqlite3* (handle to
> >> a) database is to use sqlite3_close specifying the database you want to
> >> close.
> >>
> >> --
> >> ˙uʍop-ǝpısdn sı ɹoʇıuoɯ ɹnoʎ 'sıɥʇ pɐǝɹ uɐɔ noʎ ɟı
> >>
> >>
> >> > -Original Message-
> >> > From: sqlite-users [mailto:sqlite-users-bounces@
> mailinglists.sqlite.org]
> >> > On Behalf Of Igor Korot
> >> > Sent: Friday, 14 April, 2017 08:26
> >> > To: Discussion of SQLite Database; General Discussion of SQLite
> Database
> >> > Subject: [sqlite] Create database
> >> >
> >> >  Hi,
> >> > If I have a database open with sqlite3_open() and then want to issue
> >> > another sqlite3_open(),
> >> > the old database will be closed and the new one will open?
> >> > Or I have to explicitly call sqlite3_close()?
> >> >
> >> > Thank you.
> >> > ___
> >> > sqlite-users mailing list
> >> > sqlite-users@mailinglists.sqlite.org
> >> > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
> >>
> >>
> >>
> >> ___
> >> sqlite-users mailing list
> >> sqlite-users@mailinglists.sqlite.org
> >> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
> >
> >
> >
> > ___
> > sqlite-users mailing list
> > sqlite-users@mailinglists.sqlite.org
> > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
> ___
> sqlite-users mailing list
> sqlite-users@mailinglists.sqlite.org
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
>



-- 
Daniel
*L'action accède à la perfection quand, bien que vivant, vous êtes déjà
mort*
*Bunan*
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] "struct Mem" conflicts with namespaces/classes having the same name

[Daniel Anderson]

ok, but then
namespace ns1
{
extern "C" int ert(void) { return 9; }
};

namespace ns2
{
extern "C" int ert(void);
};

are both the same function !

it would be simpler in the sqlite case to define Mem to something else
before include, and then undef it

instead of playing with namespace


2017-04-10 10:43 GMT-04:00 Olivier Mascia <o...@integral.be>:

> > Le 10 avr. 2017 à 16:21, Daniel Anderson <woni...@gmail.com> a écrit :
> >
> > as Sqlite is already within extern "C"
> >
> > I'm wondering how your namespace trick can work ?
>
>
> Both are simply unrelated.
> extern "C" is a linkage specification.
> Not a namespace declaration.
>
> --
> Best Regards, Meilleures salutations, Met vriendelijke groeten,
> Olivier Mascia, http://integral.software
>
>
> ___
> sqlite-users mailing list
> sqlite-users@mailinglists.sqlite.org
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
>



-- 
Daniel
*L'action accède à la perfection quand, bien que vivant, vous êtes déjà
mort*
*Bunan*
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] "struct Mem" conflicts with namespaces/classes having the same name

[Daniel Anderson]

as Sqlite is already within extern "C"

I'm wondering how your namespace trick can work ?



2017-04-10 9:41 GMT-04:00 Bob Friesenhahn :

> On Mon, 10 Apr 2017, Olivier Mascia wrote:
>
>>
>> This is where I do:
>>
>> #include "memory.h"
>> namespace sqlite
>> {
>> #include "sqlite3.h"
>> }
>>
>> And the conflict with your Mem goes away for the price of qualifying your
>> references to SQLite symbols with 'sqlite::'. It fits me easily because we
>> have our own slim C++ wrapper around SQLite C API, so these prefixed
>> references are only slightly annoying (length of text) in the wrapper code.
>> It might of course not fit you and having sqlite3.h not exposing that Mem
>> in the public namespace is certainly the long term better solution for
>> everyone.
>>
>
> A way to get rid of the annoying 'sqlite::' prefix for plain C functions
> is to import the functions actually planned to be used into global scope or
> into the namespace of the using code:
>
> namespace MyNamespace
> {
>   using sqlite:sqlite3_exec;
> }
>
> Bob
> --
> Bob Friesenhahn
> bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
> GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
> ___
> sqlite-users mailing list
> sqlite-users@mailinglists.sqlite.org
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
>



-- 
Daniel
*L'action accède à la perfection quand, bien que vivant, vous êtes déjà
mort*
*Bunan*
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] "struct Mem" conflicts with namespaces/classes having the same name

[Daniel Anderson]

Ah, understood.

I thought you had a struct or a class named Mem.


then short term solution is to rename Mem in sqlite.h

using the #define directive + include file should do the trick.

as they say solve it by using a level of indirection!

It will be a bit ugly, but until
a) sqlite change the name
or
b) you change the namespace name

you'll be stuck with a hack!

Cordialement!

Daniel


2017-04-10 5:11 GMT-04:00 dip :

> I am mixing C and C++ code. My code is in C++, SQLite is in C.
> Just create memory.h:
>
> namespace Mem {
> // some functions
> }
>
> And create code.cpp:
>
> #include "memory.h"
> #include "sqlite3.h"
>
> void Func()
> {
> Mem::SomeFunc(); // gives the compilation error
> }
>
> Sent with [ProtonMail](https://protonmail.com) Secure Email.
>
>  Original Message 
> Subject: Re: [sqlite] "struct Mem" conflicts with namespaces/classes
> having the same name
> Local Time: April 10, 2017 2:29 AM
> UTC Time: April 9, 2017 11:29 PM
> From: woni...@gmail.com
> To: SQLite mailing list 
>
> I see no problems with C++.
>
> Mem is only foward declared, you can redefined it to whatever you want. as
> long as you do not redefined it for sqlite.c you should be good.
>
> in sqlite.h it's declared:
>
> struct Mem;
>
> so in your code if you do:
>
> struct Mem { int a;int b;} then your definition will be used for your code.
>
> as sqlite is only using pointer, and has his own definition, I do not see
> the problem.
>
> it breaks the ODR, but as I previously said it's used/allocated internally
> by sqlite which should never see your definition.
>
> can you explain in more detail what is happening ?
>
> can you make a small reproduceable sample ?
>
> also are you mixing C++ & C, or is your code all in c ?
>
> Daniel
>
> 2017-04-09 15:49 GMT-04:00 dip :
>
> > sqlite3.c is C file. C does not support namespaces.
> > Even though another project files are .cpp, sqlite3.c is still compiled
> as
> > C language source.
> > Therefore, no ability to use "using namespace" in sqlite3.c.
> > Also, "using namespace" does not actually put functions in the source in
> > namespace. It just helps it find another functions without specifying
> > namespace name.
> >
> > Sent with [ProtonMail](https://protonmail.com) Secure Email.
> >
> >  Original Message 
> > Subject: Re: [sqlite] "struct Mem" conflicts with namespaces/classes
> > having the same name
> > Local Time: April 9, 2017 10:23 PM
> > UTC Time: April 9, 2017 7:23 PM
> > From: d3c...@gmail.com
> > To: SQLite mailing list 
> >
> > On Sun, Apr 9, 2017 at 12:20 PM, Richard Damon  >
> > wrote:
> >
> > > On 4/9/17 1:49 PM, Olivier Mascia wrote:
> > >
> > >> Le 9 avr. 2017 à 18:49, dip  a écrit :
> > >>>
> > >>> I downloaded latest SQLite Amalgamation (v 3.18.0) to embed it in my
> > >>> project.
> > >>> After that I got a lot of errors while compiling (compiler is
> Microsoft
> > >>> Visual Studio 2017).
> > >>> Errors were caused by the following line in sqlite3.h:
> > >>>
> > >>> typedef struct Mem sqlite3_value;
> > >>>
> > >>> The reason is that I have the namespace with the same name.
> > >>> So I have a suggestion to rename "struct Mem" to something else (add
> > >>> prefix to it) because "Mem" is a very common name like "input" or
> > "data" or
> > >>> "buffer" and there may be classes or namespaces having the same name.
> > >>>
> > >> The way to overcome this completely in large programmings using many
> > >> libraries is to include sqlite3.h within a namespace. Not something
> that
> > >> SQLite code must do itself: that's best handled at the user project
> > level.
> > >>
> > >> The problem with this is that if the header file is put in a namespace
> > in
> > > the user code, then the source file that defines these functions needs
> to
> > > also be changed to put the files in that same namespace, or the things
> > > being defined won't be found.
> > >
> > > think that's what 'use namespace' is for
> >
> > > --
> > > Richard Damon
> > >
> > >
> > > ___
> > > sqlite-users mailing list
> > > sqlite-users@mailinglists.sqlite.org
> > > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
> > >
> > ___
> > sqlite-users mailing list
> > sqlite-users@mailinglists.sqlite.org
> > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
> > ___
> > sqlite-users mailing list
> > sqlite-users@mailinglists.sqlite.org
> > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
> >
>
> --
> Daniel
> *L'action accède à la perfection quand, bien que vivant, vous êtes déjà
> mort*
> *Bunan*
> ___
> sqlite-users mailing list
> sqlite-users@mailinglists.sqlite.org
> 

Re: [sqlite] "struct Mem" conflicts with namespaces/classes having the same name

[Daniel Anderson]

I see no problems with C++.

Mem is only foward declared, you can redefined it to whatever you want. as
long as you do not redefined it for sqlite.c you should be good.

in sqlite.h it's declared:

struct Mem;

so in your code if you do:

struct Mem { int a;int b;} then your definition will be used for your code.

as sqlite is only using pointer, and has his own definition, I do not see
the problem.

it breaks the ODR, but as I previously said it's used/allocated internally
 by sqlite which should never see your definition.

can you explain in more detail what is happening ?

can you make a small reproduceable  sample ?

also are you mixing C++ & C, or is your code all in c ?

Daniel

2017-04-09 15:49 GMT-04:00 dip :

> sqlite3.c is C file. C does not support namespaces.
> Even though another project files are .cpp, sqlite3.c is still compiled as
> C language source.
> Therefore, no ability to use "using namespace" in sqlite3.c.
> Also, "using namespace" does not actually put functions in the source in
> namespace. It just helps it find another functions without specifying
> namespace name.
>
> Sent with [ProtonMail](https://protonmail.com) Secure Email.
>
>  Original Message 
> Subject: Re: [sqlite] "struct Mem" conflicts with namespaces/classes
> having the same name
> Local Time: April 9, 2017 10:23 PM
> UTC Time: April 9, 2017 7:23 PM
> From: d3c...@gmail.com
> To: SQLite mailing list 
>
> On Sun, Apr 9, 2017 at 12:20 PM, Richard Damon 
> wrote:
>
> > On 4/9/17 1:49 PM, Olivier Mascia wrote:
> >
> >> Le 9 avr. 2017 à 18:49, dip  a écrit :
> >>>
> >>> I downloaded latest SQLite Amalgamation (v 3.18.0) to embed it in my
> >>> project.
> >>> After that I got a lot of errors while compiling (compiler is Microsoft
> >>> Visual Studio 2017).
> >>> Errors were caused by the following line in sqlite3.h:
> >>>
> >>> typedef struct Mem sqlite3_value;
> >>>
> >>> The reason is that I have the namespace with the same name.
> >>> So I have a suggestion to rename "struct Mem" to something else (add
> >>> prefix to it) because "Mem" is a very common name like "input" or
> "data" or
> >>> "buffer" and there may be classes or namespaces having the same name.
> >>>
> >> The way to overcome this completely in large programmings using many
> >> libraries is to include sqlite3.h within a namespace. Not something that
> >> SQLite code must do itself: that's best handled at the user project
> level.
> >>
> >> The problem with this is that if the header file is put in a namespace
> in
> > the user code, then the source file that defines these functions needs to
> > also be changed to put the files in that same namespace, or the things
> > being defined won't be found.
> >
> > think that's what 'use namespace' is for
>
> > --
> > Richard Damon
> >
> >
> > ___
> > sqlite-users mailing list
> > sqlite-users@mailinglists.sqlite.org
> > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
> >
> ___
> sqlite-users mailing list
> sqlite-users@mailinglists.sqlite.org
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
> ___
> sqlite-users mailing list
> sqlite-users@mailinglists.sqlite.org
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
>



-- 
Daniel
*L'action accède à la perfection quand, bien que vivant, vous êtes déjà
mort*
*Bunan*
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Drop view “automatically” when its associated table is dropped?

[Daniel Anderson]

Yep Sybase preparse it. When you create a view/sproc/triggers/function the
objects referenced must exist or your DDL will fail.

this create some complexity when we want to recreate all the objects, order
of creation is very important.



2017-03-23 21:15 GMT-04:00 Simon Slavin :

>
> On 24 Mar 2017, at 12:45am, Domingo Alvarez Duarte 
> wrote:
>
> > It's not that complicated, sqlite already do all work right now but it
> doesn't store that information in a structured way "data dictionary".
>
> SQLite does not seem to parse views or triggers for dependencies.  If it
> did it wouldn’t allow this view or these triggers.
>
> SQLite version 3.16.0 2016-11-04 19:09:39
> Enter ".help" for usage hints.
> sqlite> CREATE TABLE ta (c1 TEXT);
> sqlite> CREATE TABLE tb (c2 TEXT, c3 TEXT);
>
> sqlite> CREATE VIEW v1 AS SELECT i1 FROM ia;
> sqlite> PRAGMA table_info(v1);
> Error: no such table: main.ia
>
> sqlite> CREATE TRIGGER t22 BEFORE INSERT ON tb
>...> FOR EACH ROW BEGIN
>...> INSERT INTO ta (fred) VALUES (new.c2);
>...> END;
> sqlite> CREATE TRIGGER t23 BEFORE INSERT ON tb
>...> FOR EACH ROW BEGIN
>...> INSERT INTO gradsad VALUES (ajsdhasd);
>...> END;
> sqlite>
>
> Simon.
> ___
> sqlite-users mailing list
> sqlite-users@mailinglists.sqlite.org
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
>



-- 
Daniel
*L'action accède à la perfection quand, bien que vivant, vous êtes déjà
mort*
*Bunan*
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Drop view “automatically” when its associated table is dropped?

[Daniel Anderson]

Sybase has one.

there is even a way to get objects dependencies, I have been working on a
project for the last 5 years using sybase (ASE). very huge project and
whenever we must alter the schema we have tools to tell us which store
proc, triggers, views will be impacted. it allow us to reach the different
stake holders impacted so they can assess how the change will impact them.

also, because the way ASE works, they must provide some way to find
dependencies, because all objects which depends on table must be recreated
when that table is changed (according to doc) if not the
view/triggers/sproc might not do what you expect or fail.

ex:
create proc ert as select * from user_table where country = 'canada'

if a column is added at the end to user_table and the proc ert is not
recreated, it will not see the new column.
if a column is drop the proc will fail to execute
if a column is added in the middle then undefined behavior.

so with that kind of behavior it is good that sybase provide a way to find
the dependencies.



2017-03-23 7:56 GMT-04:00 Simon Slavin :

>
> On 23 Mar 2017, at 11:25am, Domingo Alvarez Duarte 
> wrote:
>
> > This problem and other related with the lack of a "data dictionary" in
> sqlite,
>
> Not sure what you expect here.  Can you point me at a "data dictionary"
> for some other implementation of SQL ?
>
> Simon.
> ___
> sqlite-users mailing list
> sqlite-users@mailinglists.sqlite.org
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
>



-- 
Daniel
*L'action accède à la perfection quand, bien que vivant, vous êtes déjà
mort*
*Bunan*
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Application is crashing while performing sqlite3_prepare_v2 with sqlite version 3.15.2 (intermittently)

[Daniel Anderson]

Hi Roshak,

Looks like your top function in that thread is sqlite3_prepare_v2

So I can assume 2 things:

1 - you started a thread directly on sqlite3_prepare_v2
2- you erase part of the stack trace.

if you did 1, I can only say this is not good!

if you did 2, then you are keeping information, which is bad, as missing
info prevent helping.

if you have multiple threads, the other threads info (stack trace) could be
useful for debugging, I would suggest attaching a debugger
and looking at the other threads when the crash happens

You are using multi thread application, you are probably  victim of:
 - a race condition.
- uninitialise thread local variable
- a bug in your code
- running out of memory
- etc...

look at your logs and pay attention to things like using same handle in
more than one thread
or warning messages.
also if you can reproduce the bug with a simple program, it will then be
easier to debug.





2017-03-14 22:37 GMT-04:00 ROCHAK GUPTA :

> Hi All,
>
> I am using sqlite as library in multi-threaded environment where multiple
> applications use sqlite queries to perform get/set operations on attributes
> available in sqlite db tables. Intermittently i am seeing applications
> crashing when get operation is performed which intern call
> sqlite3_prepare_v2.
> Crash is not frequent. One thing to notice that, I never hit this issue
> when i was using 3.8.10.2 for couple of months. First time i hit the issue
> only after updating 3.15.2 recently. Could anyone please help me with this?
> Following is the GDB back trace for the same. Please let me know if this is
> a known issue and if its fixed in latest sqlite version.
> #0 0x4ffc9494 in __aeabi_memcpy8 () at ../sysdeps/arm/armv7/
> multiarch/memcpy_impl.S:352
> #1  0x4194d514 in
> whereLoopXfer (pFrom=0x19a560, pTo=0x1c14d0, db=) at
> /usr/src/debug/sqlite3/3_3.15.2.0-r0/sqlite-autoconf-
> 3150200/sqlite3.c:129646
> #2 
> whereLoopInsert
> (pTemplate=pTemplate@entry=0x19a560, pBuilder=0x1c2858, pBuilder=0x1c2858)
> at /usr/src/debug/sqlite3/3_3.15.2.0-r0/sqlite-autoconf-
> 3150200/sqlite3.c:64414
> #3  0x419700f0 in
> whereLoopAddBtree (pBuilder=0x1c2858, pBuilder@entry=0x0,
> mPrereq=7281790634533488) at /usr/src/debug/sqlite3/3_3.15.
> 2.0-r0/sqlite-autoconf-3150200/sqlite3.c:130653
> #4  0x419892fc in
> whereLoopAddAll (pBuilder=0x0) at /usr/src/debug/sqlite3/3_3.15.
> 2.0-r0/sqlite-autoconf-3150200/sqlite3.c:131229
> #5 
> sqlite3WhereBegin
> (pParse=pParse@entry=0xbec43e68, pTabList=0x0, pTabList@entry=0x1c2850,
> pWhere=pWhere@entry=0xbec43cd0, pOrderBy=, pDistinctSet=0x1c2e50,
> wctrlFlags=48760, iAuxArg=320) at /usr/src/debug/sqlite3/3_3.15.
> 2.0-r0/sqlite-autoconf-3150200/sqlite3.c:1283
> #6  0x4198d8e0 in
> sqlite3Select (pParse=pParse@entry=0xbec43e68, p=, pDest=0x0, pDest@entry
> =0xbec43e08)
> at /usr/src/debug/sqlite3/3_3.15.2.0-r0/sqlite-autoconf-
> 3150200/sqlite3.c:119546
> #7  0x419b8358 in
> yy_reduce (yyruleno=, yypParser=0x1b2990) at /usr/src/debug/sqlite3/3_3.15.
> 2.0-r0/sqlite-autoconf-3150200/sqlite3.c:135340
> #8  sqlite3Parser
> (pParse=0xbec43e68, yyminor=..., yymajor=, yyp=) at
> /usr/src/debug/sqlite3/3_3.15.2.0-r0/sqlite-autoconf-
> 3150200/sqlite3.c:5377
> #9 
> sqlite3RunParser
> (pParse=pParse@entry=0xbec43e68, zSql=0xe8  address 0xe8>,
> zSql@entry=0x198248 "SELECT  FROM  WHERE
> "..., pzErrMsg=0x1c1dd0, pzErrMsg@entry=0xbec43e58) at
> /usr/src/debug/sqlite3/3_3.15.2.0-r0/sqlite-autoconf-
> 3150200/sqlite3.c:6324
> #10  0x419bdae8
> in sqlite3Prepare (db=db@entry=0x19be78,
> zSql=zSql@entry=0x198248 "SELECT  FROM  WHERE
>  "..., nBytes=nBytes@entry=233, saveSqlFlag=-1094435176,
> saveSqlFlag@entry=1, pReprepare=pReprepare@entry=0x0, ppStmt=ppStmt@entry=
> 0xbec440d8, pzTail=pzTail@entry=0x0) at /usr/src/debug/sqlite3/3_3.15.
> 2.0-r0/sqlite-autoconf-3150200/sqlite3.c:114126
> #11  0x419bdfb4
> in sqlite3LockAndPrepare (db=0x19be78,
> zSql=0x198248 "SELECT  FROM  WHERE "...,
> nBytes=233, saveSqlFlag=1, pOld=0x0, ppStmt=0xbec440d8, pzTail=0x0) at
> /usr/src/debug/sqlite3/3_3.15.2.0-r0/sqlite-autoconf-
> 3150200/sqlite3.c:114217
> #12  0x419be27c
> in sqlite3_prepare_v2 (db=,
> zSql=zSql@entry=0x198248 "SELECT  FROM  WHERE
>  "..., nBytes=, ppStmt=ppStmt@entry=0xbec440d8,
> pzTail=pzTail@entry=0x0) at 

Re: [sqlite] Crash on Android

[Daniel Anderson]

looks like a race condition!

but it could also be uninitialized variable, but this is rarer these day as
most compiler flag uninitialized var.
unless your uninitialized var happen to be in a struct, this is why
constructor are so important for struct/class






2017-02-27 11:28 GMT-05:00 Jeff Archer :

> Hi All,
> Any thoughts on this will be greatly appreciated.
>
> I am having an issue only on a specific tablet when it is running Android
> 4.2.2.  When Android is upgraded to 4.4.2 problems appears to be gone.  I
> still want to understand root cause to know if problem is really gone.
>
> My environment is a little unusual.  I am running SQLite amalgamation
> wrapped by JDBC driver.  I was running 3.13.0 when issue was initially
> found but have updated to 3.17.0 and no change.
>
> Problem always occurs while doing same operation but unable to predict when
> it will occur.  Problem occurs while reading in a specific table and a call
> to sqlite3_column_text16() results in the following error being logged:
> A/libc(5225): Fatal signal 11 (SIGSEGV) at 0x (code=128), thread
> 5225 (saltillo.chatpc)
> and of course kills the process.
>
> Also, I find that attaching a debugger or writing too many log messages
> seems to make the problems disappear also.
>
> Thanks,
> Jeff
> ___
> sqlite-users mailing list
> sqlite-users@mailinglists.sqlite.org
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
>



-- 
Daniel
*L'action accède à la perfection quand, bien que vivant, vous êtes déjà
mort*
*Bunan*
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Problem compiling 3.17.0 in MSVS 12

[Daniel Anderson]

There is no \ at the end of the code which was pasted.

did you removed them from the source ?

the error look related to that problem.

my .02 $

2017-02-14 17:20 GMT-05:00 Simon Slavin :

>
> On 14 Feb 2017, at 10:15pm, Bart Smissaert 
> wrote:
>
> > The strange thing is that nil changed other than moving from version
> 3.16.2
> > to 3.17.0.
> > There is no serious problem as I can compile on the other PC, but would
> > like to figure out what is going on here.
> > Will see if I can look at the pre-processor output.
>
> There’s always the chance that your copy of VC (or its compiler) got
> corrupted somehow.
>
> Simon.
> ___
> sqlite-users mailing list
> sqlite-users@mailinglists.sqlite.org
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
>



-- 
Daniel
*L'action accède à la perfection quand, bien que vivant, vous êtes déjà
mort*
*Bunan*
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users