Re: [sqlite] Names of Indexes (CREATE INDEX)

[Alexander A. Gnatyna]

you can name indexes as you wish. if you use select - you should  specify 
coluns names. engine well decide what index to use depend on  CREATE INDEX 
statement and you SQL query.

On Saturday 02 May 2009 02:45:03 a a wrote:
> Do index names need to be different from field names?
> When doing selects on indexed fields, can I use the field name, or must I
> use the index name?
>
> I just want normal indexes, i'm not looking to create indexes for multiple
> fields.
>
> Can I say: CREATE INDEX x ON t (x); ?
> or does it have to be: CREATE INDEX index_t_x ON t (x); ?
> assuming the latter, can I say SELECT * FROM t ORDER BY x; or do I have to
> say ORDER BY index_t_x; to receive the speed benefit of the index.
>
> I tried CREATE INDEX x ON t (x); in SQLite3.exe, and no error was reported,
> but I don't want to assume anything.
>
> This is extremely ambiguous and confusing.
> I've got enough field names, I don't want to have to start dealing with
> unique index names as well in SELECT/INSERT/UPDATE queries.
>
> Thanks for the help. Feeling very frustrated atm.
> ___
> sqlite-users mailing list
> sqlite-users@sqlite.org
> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users


___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Names of Indexes (CREATE INDEX)

[Igor Tandetnik]

a a  wrote:
> Do index names need to be different from field names?

No.

> When doing selects on indexed fields, can I use the field name, or
> must I use the index name?

You must use the field name, you cannot use index name. An index will be 
used automatically if the engine deems it beneficial.

> Can I say: CREATE INDEX x ON t (x); ?

Yes.

> or does it have to be: CREATE INDEX index_t_x ON t (x); ?

This is valid, too.

> assuming the latter, can I say SELECT * FROM t ORDER BY x;

Yes.

> or do I
> have to say ORDER BY index_t_x;

No. In fact, it won't work, you'll get a syntax error.

> This is extremely ambiguous and confusing.

What specifically seems to be the problem?

> I've got enough field names, I don't want to have to start dealing
> with unique index names as well in SELECT/INSERT/UPDATE queries.

Wherever did you get the idea in the first place?

Igor Tandetnik



___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] mutex and begin/end transaction

[Douglas E. Fajardo]

Gentlefolk:

Sorry to be a 'wet blanket' here, but while this thread is an interesting 
debate, *this* list is about SQLITE, not the Scientific Method... As an 
observer on the sidelines, I would suggest that this discussion has strayed a 
little bit off topic :-)

 Uh... does anyone remember what this thread was *really* about? Oh yes, 
something about Mutexes and transactions...

*** Doug Fajardo


-Original Message-
From: sqlite-users-boun...@sqlite.org [mailto:sqlite-users-boun...@sqlite.org] 
On Behalf Of James Gregurich
Sent: Friday, May 01, 2009 10:02 AM
To: General Discussion of SQLite Database
Subject: Re: [sqlite] mutex and begin/end transaction


I describe reality.

Someone has to be the arbiter of "better." Generally, that arbiter is  
the guy handing out the research grants.

On May 1, 2009, at 5:33 AM, John Stanton wrote:

>
> Science is the Scientific Method - observation, hypothesis and
> skepticism.  The antithesis of politics.  There are no facts in  
> science,
> only observations and any hypothesis is only valid until a better one
> replaces it.
>
> You describe bad, politicized science.
>
> James Gregurich wrote:
>> With all due respect,  science itself is a set of
>> "positions" (opinions) which are endorsed by small group of people as
>> official doctrine after appropriate study. Saying "A 'position' is
>> politics, not science" is not a particularly meaningful statement.   
>> If
>> you want to argue that point, feel free to send me a private email.
>>
>> My threaded application works pretty darn well. I can process
>> thousands of print industry files on an 8-core system keeping the
>> cores busy without lagging the GUI for other applications. Just
>> because many people create ill conceived programs doesn't mean
>> threaded programs are inherently doomed to be ill-conceived. The
>> development tools and techniques for building concurrent systems are
>> advancing and making concurrency quite feasible.
>>
>> James Gregurich
>> Engineering Manager
>> Markzware
>>
>> On Apr 30, 2009, at 5:01 AM, John Stanton wrote:
>>
>>> A "position" is politics, not science.  Warnings about the use of
>>> threads are based on science, and advise you to avoid them if  
>>> possible
>>> for your own protection.
>>>
>>> I see ill conceived programs using threads which go to complex
>>> synchronization to achieve the equivalent of single stream execution
>>> but
>>> with much greater overhead.  A KISS situation.
>>>
>>> James Gregurich wrote:
 thanks for the info. That should work for me.

 Given the industry is going multicore and 16-core macintoshes for
 your
 grand-mother are  just a few years away, I recommend you rethink  
 your
 position on the use of threading. Apple is heavily pushing
 parallelism
 on its developers.  NSOperation is a major part of that effort.  
 As I
 understand it, MS is developing their copy of NSOperation for  
 VS2010.
 The development landscape is only going to get more threaded as  
 time
 goes on.

 -James



> On Apr 29, 2009, at 10:03 PM, James Gregurich wrote:
>
>
>> howdy!
>>
>> question:
>>
>> for an in-memory db with the threading mode set to serialized, is
>>
> the
>
>> internal mutex held for an entire transaction so that one thread
>>
> won't
>
>> access the db while another one is in the middle of a transaction
>>
> with
>
>> multiple insert statements?
>>
> No.  But the mutex is recursive.  So you can get a copy of it  
> using
> sqlite3_db_mutex() then lock it yourself using
> sqlite3_mutex_enter()/
> leave().
>
> Also remember:  You should not be using threads.  Threads will  
> bring
> only grief and woe.  On your own head be it.
>
>
>
> D. Richard Hipp
> drh at hwaci.com
>
>
 ___
 sqlite-users mailing list
 sqlite-users@sqlite.org
 http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

>>> ___
>>> sqlite-users mailing list
>>> sqlite-users@sqlite.org
>>> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
>>
>> ___
>> sqlite-users mailing list
>> sqlite-users@sqlite.org
>> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
>
> ___
> sqlite-users mailing list
> sqlite-users@sqlite.org
> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

[sqlite] Names of Indexes (CREATE INDEX)

[a a]

Do index names need to be different from field names?
When doing selects on indexed fields, can I use the field name, or must I
use the index name?

I just want normal indexes, i'm not looking to create indexes for multiple
fields.

Can I say: CREATE INDEX x ON t (x); ?
or does it have to be: CREATE INDEX index_t_x ON t (x); ?
assuming the latter, can I say SELECT * FROM t ORDER BY x; or do I have to
say ORDER BY index_t_x; to receive the speed benefit of the index.

I tried CREATE INDEX x ON t (x); in SQLite3.exe, and no error was reported,
but I don't want to assume anything.

This is extremely ambiguous and confusing.
I've got enough field names, I don't want to have to start dealing with
unique index names as well in SELECT/INSERT/UPDATE queries.

Thanks for the help. Feeling very frustrated atm.
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] mutex and begin/end transaction

[John Stanton]

The better sales pitch and better political connections persuade the 
granter of research grants.  Better design and better science proves 
itself by performance and success in the marketplace and bad design and 
bad science consumes the grant without productivity.

This has strayed from the topic.  It should get back to Sqlite.

James Gregurich wrote:
> I describe reality.
> 
> Someone has to be the arbiter of "better." Generally, that arbiter is  
> the guy handing out the research grants.
> 
> On May 1, 2009, at 5:33 AM, John Stanton wrote:
> 
>> Science is the Scientific Method - observation, hypothesis and
>> skepticism.  The antithesis of politics.  There are no facts in  
>> science,
>> only observations and any hypothesis is only valid until a better one
>> replaces it.
>>
>> You describe bad, politicized science.
>>
>> James Gregurich wrote:
>>> With all due respect,  science itself is a set of
>>> "positions" (opinions) which are endorsed by small group of people as
>>> official doctrine after appropriate study. Saying "A 'position' is
>>> politics, not science" is not a particularly meaningful statement.   
>>> If
>>> you want to argue that point, feel free to send me a private email.
>>>
>>> My threaded application works pretty darn well. I can process
>>> thousands of print industry files on an 8-core system keeping the
>>> cores busy without lagging the GUI for other applications. Just
>>> because many people create ill conceived programs doesn't mean
>>> threaded programs are inherently doomed to be ill-conceived. The
>>> development tools and techniques for building concurrent systems are
>>> advancing and making concurrency quite feasible.
>>>
>>> James Gregurich
>>> Engineering Manager
>>> Markzware
>>>
>>> On Apr 30, 2009, at 5:01 AM, John Stanton wrote:
>>>
 A "position" is politics, not science.  Warnings about the use of
 threads are based on science, and advise you to avoid them if  
 possible
 for your own protection.

 I see ill conceived programs using threads which go to complex
 synchronization to achieve the equivalent of single stream execution
 but
 with much greater overhead.  A KISS situation.

 James Gregurich wrote:
> thanks for the info. That should work for me.
>
> Given the industry is going multicore and 16-core macintoshes for
> your
> grand-mother are  just a few years away, I recommend you rethink  
> your
> position on the use of threading. Apple is heavily pushing
> parallelism
> on its developers.  NSOperation is a major part of that effort.  
> As I
> understand it, MS is developing their copy of NSOperation for  
> VS2010.
> The development landscape is only going to get more threaded as  
> time
> goes on.
>
> -James
>
>
>
>> On Apr 29, 2009, at 10:03 PM, James Gregurich wrote:
>>
>>
>>> howdy!
>>>
>>> question:
>>>
>>> for an in-memory db with the threading mode set to serialized, is
>>>
>> the
>>
>>> internal mutex held for an entire transaction so that one thread
>>>
>> won't
>>
>>> access the db while another one is in the middle of a transaction
>>>
>> with
>>
>>> multiple insert statements?
>>>
>> No.  But the mutex is recursive.  So you can get a copy of it  
>> using
>> sqlite3_db_mutex() then lock it yourself using
>> sqlite3_mutex_enter()/
>> leave().
>>
>> Also remember:  You should not be using threads.  Threads will  
>> bring
>> only grief and woe.  On your own head be it.
>>
>>
>>
>> D. Richard Hipp
>> drh at hwaci.com
>>
>>
> ___
> sqlite-users mailing list
> sqlite-users@sqlite.org
> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
>
 ___
 sqlite-users mailing list
 sqlite-users@sqlite.org
 http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
>>> ___
>>> sqlite-users mailing list
>>> sqlite-users@sqlite.org
>>> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
>> ___
>> sqlite-users mailing list
>> sqlite-users@sqlite.org
>> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
> 
> ___
> sqlite-users mailing list
> sqlite-users@sqlite.org
> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Strict affinity again

[Florian Weimer]

* D. Richard Hipp:

> SQLite is strongly typed,

Curiously, it's even more strongly typed than SQL:

sqlite> SELECT 1 = '1';
0

fw=> SELECT 1 = '1';
 ?column?
--
 t
(1 row)

(In SQL, quoted values are not of string type, but their type is
inferred from context.)
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] mutex and begin/end transaction

[James Gregurich]

I describe reality.

Someone has to be the arbiter of "better." Generally, that arbiter is  
the guy handing out the research grants.

On May 1, 2009, at 5:33 AM, John Stanton wrote:

>
> Science is the Scientific Method - observation, hypothesis and
> skepticism.  The antithesis of politics.  There are no facts in  
> science,
> only observations and any hypothesis is only valid until a better one
> replaces it.
>
> You describe bad, politicized science.
>
> James Gregurich wrote:
>> With all due respect,  science itself is a set of
>> "positions" (opinions) which are endorsed by small group of people as
>> official doctrine after appropriate study. Saying "A 'position' is
>> politics, not science" is not a particularly meaningful statement.   
>> If
>> you want to argue that point, feel free to send me a private email.
>>
>> My threaded application works pretty darn well. I can process
>> thousands of print industry files on an 8-core system keeping the
>> cores busy without lagging the GUI for other applications. Just
>> because many people create ill conceived programs doesn't mean
>> threaded programs are inherently doomed to be ill-conceived. The
>> development tools and techniques for building concurrent systems are
>> advancing and making concurrency quite feasible.
>>
>> James Gregurich
>> Engineering Manager
>> Markzware
>>
>> On Apr 30, 2009, at 5:01 AM, John Stanton wrote:
>>
>>> A "position" is politics, not science.  Warnings about the use of
>>> threads are based on science, and advise you to avoid them if  
>>> possible
>>> for your own protection.
>>>
>>> I see ill conceived programs using threads which go to complex
>>> synchronization to achieve the equivalent of single stream execution
>>> but
>>> with much greater overhead.  A KISS situation.
>>>
>>> James Gregurich wrote:
 thanks for the info. That should work for me.

 Given the industry is going multicore and 16-core macintoshes for
 your
 grand-mother are  just a few years away, I recommend you rethink  
 your
 position on the use of threading. Apple is heavily pushing
 parallelism
 on its developers.  NSOperation is a major part of that effort.  
 As I
 understand it, MS is developing their copy of NSOperation for  
 VS2010.
 The development landscape is only going to get more threaded as  
 time
 goes on.

 -James



> On Apr 29, 2009, at 10:03 PM, James Gregurich wrote:
>
>
>> howdy!
>>
>> question:
>>
>> for an in-memory db with the threading mode set to serialized, is
>>
> the
>
>> internal mutex held for an entire transaction so that one thread
>>
> won't
>
>> access the db while another one is in the middle of a transaction
>>
> with
>
>> multiple insert statements?
>>
> No.  But the mutex is recursive.  So you can get a copy of it  
> using
> sqlite3_db_mutex() then lock it yourself using
> sqlite3_mutex_enter()/
> leave().
>
> Also remember:  You should not be using threads.  Threads will  
> bring
> only grief and woe.  On your own head be it.
>
>
>
> D. Richard Hipp
> drh at hwaci.com
>
>
 ___
 sqlite-users mailing list
 sqlite-users@sqlite.org
 http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

>>> ___
>>> sqlite-users mailing list
>>> sqlite-users@sqlite.org
>>> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
>>
>> ___
>> sqlite-users mailing list
>> sqlite-users@sqlite.org
>> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
>
> ___
> sqlite-users mailing list
> sqlite-users@sqlite.org
> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Errors with quickstart.html's C example

[Samuel Baldwin]

2009/5/1 John Stanton :
> What is your make file?  It seems to be missing a link library.

I hadn't gotten to that point yet. But, as the other email said,
linking to sqlite3 does magic.
-- 
Samuel 'Shardz' Baldwin - staticfree.info/~samuel
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Errors with quickstart.html's C example

[John Stanton]

What is your make file?  It seems to be missing a link library.

Samuel Baldwin wrote:
> Howdy. When I try to compile the small C program at the bottom of
> http://www.sqlite.org/quickstart.html , I get the following errors:
> 
> arrakis^library% gcc test.c
> test.c: In function ‘main’:
> test.c:21: warning: incompatible implicit declaration of built-in
> function ‘exit’
> test.c:27: warning: incompatible implicit declaration of built-in
> function ‘exit’
> /tmp/ccYuZFw7.o: In function `main':
> test.c:(.text+0xc0): undefined reference to `sqlite3_open'
> test.c:(.text+0xd2): undefined reference to `sqlite3_errmsg'
> test.c:(.text+0xf4): undefined reference to `sqlite3_close'
> test.c:(.text+0x123): undefined reference to `sqlite3_exec'
> test.c:(.text+0x14f): undefined reference to `sqlite3_free'
> test.c:(.text+0x158): undefined reference to `sqlite3_close'
> collect2: ld returned 1 exit status
> 
> The warnings about exit() are removed if I add #include ,
> but then I'm left with:
> 
> arrakis^library% gcc test.c
> /tmp/ccENlzA6.o: In function `main':
> test.c:(.text+0xc0): undefined reference to `sqlite3_open'
> test.c:(.text+0xd2): undefined reference to `sqlite3_errmsg'
> test.c:(.text+0xf4): undefined reference to `sqlite3_close'
> test.c:(.text+0x123): undefined reference to `sqlite3_exec'
> test.c:(.text+0x14f): undefined reference to `sqlite3_free'
> test.c:(.text+0x158): undefined reference to `sqlite3_close'
> collect2: ld returned 1 exit status
> 
> I'm really not sure what else to do. I've tried this on two machines
> running two seperate linux distributions, and friends have confirmed
> the same error on yet other machines. Is the sample code just
> outdated? Looking over it and sqlite3.h makes me think it should work.
> 
> I'm running sqlite3 3.6.13
> 
> Thanks, I'm completely baffled.
> 

___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] mutex and begin/end transaction

[John Stanton]

Science is the Scientific Method - observation, hypothesis and 
skepticism.  The antithesis of politics.  There are no facts in science, 
only observations and any hypothesis is only valid until a better one 
replaces it.

You describe bad, politicized science.

James Gregurich wrote:
> With all due respect,  science itself is a set of  
> "positions" (opinions) which are endorsed by small group of people as  
> official doctrine after appropriate study. Saying "A 'position' is  
> politics, not science" is not a particularly meaningful statement.  If  
> you want to argue that point, feel free to send me a private email.
> 
> My threaded application works pretty darn well. I can process  
> thousands of print industry files on an 8-core system keeping the  
> cores busy without lagging the GUI for other applications. Just  
> because many people create ill conceived programs doesn't mean  
> threaded programs are inherently doomed to be ill-conceived. The  
> development tools and techniques for building concurrent systems are  
> advancing and making concurrency quite feasible.
> 
> James Gregurich
> Engineering Manager
> Markzware
> 
> On Apr 30, 2009, at 5:01 AM, John Stanton wrote:
> 
>> A "position" is politics, not science.  Warnings about the use of
>> threads are based on science, and advise you to avoid them if possible
>> for your own protection.
>>
>> I see ill conceived programs using threads which go to complex
>> synchronization to achieve the equivalent of single stream execution  
>> but
>> with much greater overhead.  A KISS situation.
>>
>> James Gregurich wrote:
>>> thanks for the info. That should work for me.
>>>
>>> Given the industry is going multicore and 16-core macintoshes for  
>>> your
>>> grand-mother are  just a few years away, I recommend you rethink your
>>> position on the use of threading. Apple is heavily pushing  
>>> parallelism
>>> on its developers.  NSOperation is a major part of that effort. As I
>>> understand it, MS is developing their copy of NSOperation for VS2010.
>>> The development landscape is only going to get more threaded as time
>>> goes on.
>>>
>>> -James
>>>
>>>
>>>
 On Apr 29, 2009, at 10:03 PM, James Gregurich wrote:


> howdy!
>
> question:
>
> for an in-memory db with the threading mode set to serialized, is
>
 the

> internal mutex held for an entire transaction so that one thread
>
 won't

> access the db while another one is in the middle of a transaction
>
 with

> multiple insert statements?
>
 No.  But the mutex is recursive.  So you can get a copy of it using
 sqlite3_db_mutex() then lock it yourself using  
 sqlite3_mutex_enter()/
 leave().

 Also remember:  You should not be using threads.  Threads will bring
 only grief and woe.  On your own head be it.



 D. Richard Hipp
 drh at hwaci.com


>>> ___
>>> sqlite-users mailing list
>>> sqlite-users@sqlite.org
>>> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
>>>
>> ___
>> sqlite-users mailing list
>> sqlite-users@sqlite.org
>> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
> 
> ___
> sqlite-users mailing list
> sqlite-users@sqlite.org
> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] mutex and begin/end transaction

[John Stanton]

I suggest that you peruse the source code of Pthreads to get some idea 
of what you do when you create a thread.  They are not, as some people 
appear to believe, a magic way of making the machine do more and go faster.

Threads are of course invaluable when you want one resource, such as a 
user, to have access to multiple resources.

When you have multiple threads accessing one resource, such as a 
database, then you must have a robust synchronization method, such as a 
mutex, queue or similar.  There is a danger that programmers will 
implement a busy wait to perform their synchronization and get poor 
performance. In some low level, low latency cases however the use of the 
ultimate busy wait, a spin lock, is the best approach.

Pavel Ivanov wrote:
> So you don't even try to argue about database-servers-like
> applications? Apache maybe indeed not very good example because of
> good degree of independence between threads, though I think in some
> cases caching across different connections and thus across different
> threads could be useful.
> 
>> The danger with threading is in concurrent access to data.
> 
> I understand that. That's why concurrent access should be made very
> wisely. But if this concurrent access is to some cache which allows to
> avoid huge amount of disk reads - it's worth the effort. And my
> overall point here is that there's no universal taboo "threads are
> evil in all cases". It totally depends on the type of application.
> 
> Pavel
> 
> On Thu, Apr 30, 2009 at 2:54 PM, Roger Binns  wrote:
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>> Pavel Ivanov wrote:
>>> I'm curious: with all these "warnings based on science" how would you
>>> implement application similar to apache web-server
>> The danger with threading is in concurrent access to data.  Apache has
>> several different modes of operation (forking etc) but in the one that
>> uses threading, each thread handles a connection and does not handle or
>> share any data with other threads during its operation on that
>> connection.  For the non-Windows worker (MPM) it also uses multiple
>> processes with multiple threads and the processes exit after handling a
>> certain number of requests.
>>
>> As an example you can read about mod_wsgi which provides for running
>> Python code as though it was CGI - see http://code.google.com/p/modwsgi/
>>
>> Roger
>> -BEGIN PGP SIGNATURE-
>> Version: GnuPG v1.4.9 (GNU/Linux)
>>
>> iEYEARECAAYFAkn58/MACgkQmOOfHg372QSoOQCfXvz8ef7vS0HP/Uc9hZ/1BQSO
>> Cw0AoMXzgpNwO0PA5uMBvG/DB2Y3lKHG
>> =Cage
>> -END PGP SIGNATURE-
>> ___
>> sqlite-users mailing list
>> sqlite-users@sqlite.org
>> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
>>
> ___
> sqlite-users mailing list
> sqlite-users@sqlite.org
> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] mutex and begin/end transaction

[James Gregurich]

So, you suggest I should build a commercial desktop application (for  
processing print-industry files and presenting them in a UI)  in such  
a way that it spawns multiple processes and communicates with them via  
the filesystem or IPC APIs?

Why would I want to go to that level of complexity in an  
uncontrollable environment (i.e. a consumer desktop computer) when I  
can just use NSOperation, boost::thread, and boost::mutex to build a  
single-process solution that shares data in a normal way between tasks?

James Gregurich
Engineering Manager
Markzware


On Apr 29, 2009, at 11:23 PM, Roger Binns wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> James Gregurich wrote:
>> Given the industry is going multicore and 16-core macintoshes for  
>> your
>> grand-mother are  just a few years away, I recommend you rethink your
>> position on the use of threading.
>
> Threading is the worst solution to many cpu/core and large memory.
> Having the same memory addressed (which is what threading does) across
> multiple concurrently executing cpus/cores causes cache thrashing,
> memory contention, frequent use of memory barriers for synchronization
> (which also slows things down) and as memory becomes attached to
> individual cpus leads to access being over hypertransport/csi.
>
> Far better is using multiple processes which don't have those  
> issues.  A
> good example application to study is Google Chrome which uses multiple
> processes prolifically - each tab is a separate process, as well as  
> the
> various plugins, languages etc.  Each process can be appropriately
> locked down using the principle of least privilege.  If you use  
> threads
> then typically they all have permission to do anything the process  
> could do.
>
> (Also the multi-process approach is way easier to test, record/replay
> and is more deterministic)
>
> Erlang is also worth studying.  It only has single threaded processes
> (although the processes are lighter weight than operating system  
> processes).
>
>> NSOperation is a major part of that effort.
>
> If the "single encapsulated task" doesn't go around concurrently
> touching bits of memory then it could be shunted to a separate process
> anyway.
>
> The danger from threads is not the threads themselves, but the
> concurrency.  It is virtually impossible to prove that a threaded
> process does the concurrency correctly under all circumstances.  If  
> you
> eliminate the concurrency then you can use multiple processes, and can
> usually even make it scale over multiple machines!
>
> Roger
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.9 (GNU/Linux)
>
> iEYEARECAAYFAkn5Q9MACgkQmOOfHg372QSS/QCfSje/tyX0hmidHyubVKqrXlHt
> Sq0AoKEbmcwx/fmAFtcVeMjbcUgN8dr3
> =8lUQ
> -END PGP SIGNATURE-
> ___
> sqlite-users mailing list
> sqlite-users@sqlite.org
> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] A memvfs for loading/saving database from buffer

[stephen liu]

> It also sounds like you are operating in an environment that is almost
> entirely reading and with lots of memory.  You could still store one


Yes. The memvfs requires to entirely reading the database.
So this solution is just for something like addressbook application,
the data for one user is small enough, we can accept to entirely read.
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] A memvfs for loading/saving database from buffer

[stephen liu]

http://spserver.googlecode.com/files/spmemvfs-0.1.src.tar.gz

Changes:
* Modify the save callback, transfer the ownership of the buffer to callback
function
* Add a buffer map to pass buffer between application and sqlite3 vfs

The demo code:

static void * load( void * arg, const char * path, int * len )
{
spmembuffer_map_t * themap = (spmembuffer_map_t*)arg;
char * ret = spmembuffer_map_take( themap, path, len );
return ret;
}

static int save( void * arg, const char * path, char * buffer, int len )
{
spmembuffer_map_t * themap = (spmembuffer_map_t*)arg;
return spmembuffer_map_put( themap, path, buffer, len );
}

int main( int argc, char * argv[] )
{
spmembuffer_map_t * themap = spmembuffer_map_new();
spmemvfs_cb_t cb = { themap, load, save };
const char * path = "abc.db";

spmemvfs_init(  );

// load membuffer from file, put it into themap
{
char * buffer = NULL;
int len = 0;
buffer = read_buffer_from_file( path,  );
spmembuffer_map_put( themap, path, buffer, len );
}

// open sqlite by sqlite3_open_v2
{
sqlite3 * dbHandle = NULL;
char errcode = sqlite3_open_v2( path, ,
SQLITE_OPEN_READWRITE | SQLITE_OPEN_CREATE, SPMEMVFS_NAME );

// do wahtever you want
..
}

// get membuffer from themap, save it to file
{
int len = 0;
char * buffer = (char*)spmembuffer_map_take( themap, path,  );
save_buffer_to_file( path, buffer, len );
free( buffer );
}

spmembuffer_map_del( themap );

return 0;
}
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Errors with quickstart.html's C example

[Samuel Baldwin]

Please, someone troll me like Theo de Raadt responding to someone
saying OpenBSD is insecure...

`gcc -lsqlite3 test.c' works like a charm.
-- 
Samuel 'Shardz' Baldwin - staticfree.info/~samuel
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

[sqlite] Errors with quickstart.html's C example

[Samuel Baldwin]

Howdy. When I try to compile the small C program at the bottom of
http://www.sqlite.org/quickstart.html , I get the following errors:

arrakis^library% gcc test.c
test.c: In function ‘main’:
test.c:21: warning: incompatible implicit declaration of built-in
function ‘exit’
test.c:27: warning: incompatible implicit declaration of built-in
function ‘exit’
/tmp/ccYuZFw7.o: In function `main':
test.c:(.text+0xc0): undefined reference to `sqlite3_open'
test.c:(.text+0xd2): undefined reference to `sqlite3_errmsg'
test.c:(.text+0xf4): undefined reference to `sqlite3_close'
test.c:(.text+0x123): undefined reference to `sqlite3_exec'
test.c:(.text+0x14f): undefined reference to `sqlite3_free'
test.c:(.text+0x158): undefined reference to `sqlite3_close'
collect2: ld returned 1 exit status

The warnings about exit() are removed if I add #include ,
but then I'm left with:

arrakis^library% gcc test.c
/tmp/ccENlzA6.o: In function `main':
test.c:(.text+0xc0): undefined reference to `sqlite3_open'
test.c:(.text+0xd2): undefined reference to `sqlite3_errmsg'
test.c:(.text+0xf4): undefined reference to `sqlite3_close'
test.c:(.text+0x123): undefined reference to `sqlite3_exec'
test.c:(.text+0x14f): undefined reference to `sqlite3_free'
test.c:(.text+0x158): undefined reference to `sqlite3_close'
collect2: ld returned 1 exit status

I'm really not sure what else to do. I've tried this on two machines
running two seperate linux distributions, and friends have confirmed
the same error on yet other machines. Is the sample code just
outdated? Looking over it and sqlite3.h makes me think it should work.

I'm running sqlite3 3.6.13

Thanks, I'm completely baffled.

-- 
Samuel 'Shardz' Baldwin - staticfree.info/~samuel
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users