Christian Smith wrote:
On Thu, 6 May 2004, Puneet Kishor wrote:
Things that SQLite sucks at (if you pardon the expression) compared to
Access and FMPro -- ALTERing tables is a royal pain in the behind. I am
constantly in need of ALTERing the tables and queries (views) as I am
developing the appl
On Thu, 6 May 2004, Puneet Kishor wrote:
>
>Things that SQLite sucks at (if you pardon the expression) compared to
>Access and FMPro -- ALTERing tables is a royal pain in the behind. I am
>constantly in need of ALTERing the tables and queries (views) as I am
>developing the application, and to do
On Fri, May 07, 2004 at 09:22:59AM +0100, Paul Smith wrote:
> Given that (IMHO) most concurrency problems seem to be centred around a
> single application with multiple threads, might it not be possible for that
> application to 'register' with SQLite in order to implement table locks.
> Simila
At 17:22 06/05/2004, D. Richard Hipp wrote:
Thomas, Basil wrote:
> I am no technical expert but...could not page locking at least be
implemented
> by the pager module to increase concurrency(very naive...but better
than file
> locking).
>
Page-level locking will not help. For one thing, we cann
estion
whether the developers at MS "...have a clue". I'm not saying it's the best
or fastest but it must have something going for it...
Steve
-Original Message-
From: Puneet Kishor [mailto:[EMAIL PROTECTED]
Sent: 06 May 2004 18:59
To: [EMAIL PROTECTED]
Cc: [EMAI
On Thu, May 06, 2004 at 03:20:13PM -0400, Andrew Piskorski wrote:
> - User defined types, aka good "object" support (Date's "Third
> Manifesto").
>
> - Native bi-temporal support, or even just good support for one of
> valid-time or transaction-time (Snodgrass). This one in particular I
> would
On Thu, May 06, 2004 at 01:21:28PM -0500, Puneet Kishor wrote:
> Frankly, I am not sure if there is anything exciting left in relational
> databases to discover or create... most has been created and
> well-tested over the past 3 decades. What is left is making a tool
No way, that is not true!
On May 6, 2004, at 2:06 PM, Andrew Piskorski wrote:
On Thu, May 06, 2004 at 01:21:28PM -0500, Puneet Kishor wrote:
they are as real a database as one wants them to be. Sure, they don't
support ACID compliance, but I am not sure if they are created by
Ugh, that particular argument is one I should
On Thu, May 06, 2004 at 01:21:28PM -0500, Puneet Kishor wrote:
> they are as real a database as one wants them to be. Sure, they don't
> support ACID compliance, but I am not sure if they are created by
Ugh, that particular argument is one I should not have started. My
apologies to all, and le
In the spirit of discussion --
On May 6, 2004, at 1:08 PM, Andrew Piskorski wrote:
On Thu, May 06, 2004 at 06:24:10PM +0100, Steve O'Hara wrote:
However, I'm wondering why we're comparing SQLite with kernel based
RDBMS
like Oracle etc, and not with it's more closely related cousins such
as
Acc
On Thu, May 06, 2004 at 06:24:10PM +0100, Steve O'Hara wrote:
> However, I'm wondering why we're comparing SQLite with kernel based RDBMS
> like Oracle etc, and not with it's more closely related cousins such as
> Access ?
In my case, because I am very familiar with Oracle, somewhat less so
with
On May 6, 2004, at 12:24 PM, Steve O'Hara wrote:
I've been watching the discussion about concurrency with interest. I
find
I'm impressed by everybody's arguments.
I'd too would like to keep SQLite small and fast but equally, I'd like
to
have better concurrency. Even if this is just a safeguar
y more features
have been requested...such as supporting more users!!!
-Original Message-
From: Andrew Piskorski [mailto:[EMAIL PROTECTED]
Sent: Thursday, May 06, 2004 12:53 PM
To: [EMAIL PROTECTED]
Subject: Re: [sqlite] vers 3.0 concurrency issues
On Thu, May 06, 2004 at 09:54:24AM -040
requested...such as supporting more users!!!
-Original Message-
From: Andrew Piskorski [mailto:[EMAIL PROTECTED]
Sent: Thursday, May 06, 2004 12:53 PM
To: [EMAIL PROTECTED]
Subject: Re: [sqlite] vers 3.0 concurrency issues
On Thu, May 06, 2004 at 09:54:24AM -0400, D. Richard Hipp wrote
i [mailto:[EMAIL PROTECTED]
Sent: 06 May 2004 17:53
To: [EMAIL PROTECTED]
Subject: Re: [sqlite] vers 3.0 concurrency issues
On Thu, May 06, 2004 at 09:54:24AM -0400, D. Richard Hipp wrote:
> Concurrency is not nearly as much an issue in reality
> as it is in many peoples imagination. Concur
regards increased concurrency???
-Original Message-
From: D. Richard Hipp [mailto:[EMAIL PROTECTED]
Sent: Thursday, May 06, 2004 12:23 PM
To: [EMAIL PROTECTED]
Subject: Re: [sqlite] vers 3.0 concurrency issues
Thomas, Basil wrote:
> I am no technical expert but...could not page locking
On Thu, May 06, 2004 at 09:54:24AM -0400, D. Richard Hipp wrote:
> Concurrency is not nearly as much an issue in reality
> as it is in many peoples imagination. Concurrency
> probably is not an issue for a website. If concurrency
> really is an issue, you need a client/server database.
While tha
ith that.
A suggested solution is documented here:
http://www.sqlite.org/cvstrac/wiki?p=BlueSky
Christian
>
>
>-Original Message-
>From: Christian Smith [mailto:[EMAIL PROTECTED]
>Sent: Thursday, May 06, 2004 9:38 AM
>To: Thomas, Basil
>Cc: [EMAIL PROTECTED]
>Subject: Re: [sql
I'm testing sqlite on a network (Windows 2003 Server) share and with 5 users. I've
created a "server" program which is ran from the same directory as the shared
database. The program that the 5 users have, will read only from the sqlite database
in that directory. Whenever they want to add a
Thomas, Basil wrote:
> I am no technical expert but...could not page locking at least be implemented
> by the pager module to increase concurrency(very naive...but better than file
> locking).
>
Page-level locking will not help. For one thing, we cannot do both page-level
locking and reader/writer
> > [U]se the right tool for the job. If you require concurrent
> > readers/writer(s), then you may be better off using a full blown
> > client/server database, especially in a distributed
> environment. SQLite is
> > designed to be embedded, don't just use it because you can.
> >
>
> Concurre
Christian Smith wrote:
>
> [U]se the right tool for the job. If you require concurrent
> readers/writer(s), then you may be better off using a full blown
> client/server database, especially in a distributed environment. SQLite is
> designed to be embedded, don't just use it because you can.
>
Conc
not page locking at least be
implemented by the pager module to increase concurrency(very naive...but
better than file locking).
-Original Message-
From: Christian Smith [mailto:[EMAIL PROTECTED]
Sent: Thursday, May 06, 2004 9:38 AM
To: Thomas, Basil
Cc: [EMAIL PROTECTED]
Subject: R
With the pending 3.0, I think we are at a juncture so to speak. We all
like/use SQLite because it is very lightweight, fast, and above all simple.
One of the major reasons this is so, is due to the very limited and focused
functionality. Once SQLite becomes more "functional" all of these appealin
On Thu, 6 May 2004 [EMAIL PROTECTED] wrote:
>
>I would like to use SQLite on a web server or .net remoting and
>multi-user/threads may become an issue
>as locking is based at the finest granularity of file locking instead of
>table/page/row locking. Will this issue be resolved from 3.x onwards so
25 matches
Mail list logo
