Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #85771 > unrolled thread

Re: sqlite3 and dates

Back to article view | Back to comp.lang.python

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: sqlite3 and dates Chris Angelico <rosuav@gmail.com> - 2015-02-18 18:05 +1100
    Re: sqlite3 and dates Johannes Bauer <dfnsonfsduifb@gmx.de> - 2015-02-18 12:11 +0100
      Re: sqlite3 and dates Chris Angelico <rosuav@gmail.com> - 2015-02-18 22:21 +1100
        Re: sqlite3 and dates Johannes Bauer <dfnsonfsduifb@gmx.de> - 2015-02-18 12:57 +0100
          Re: sqlite3 and dates Chris Angelico <rosuav@gmail.com> - 2015-02-18 23:14 +1100
            Re: sqlite3 and dates Johannes Bauer <dfnsonfsduifb@gmx.de> - 2015-02-18 14:13 +0100
            Not sqlite3 and dates Steve Hayes <hayesstw@telkomsa.net> - 2015-02-19 04:53 +0200
          Re: sqlite3 and dates Adam Funk <a24061@ducksburg.com> - 2015-02-19 13:18 +0000
        Re: sqlite3 and dates rurpy@yahoo.com - 2015-02-18 14:17 -0800
          Re: sqlite3 and dates Chris Angelico <rosuav@gmail.com> - 2015-02-19 09:37 +1100
            Not sqlite3 and dates Steve Hayes <hayesstw@telkomsa.net> - 2015-02-19 04:54 +0200
            Re: sqlite3 and dates Adam Funk <a24061@ducksburg.com> - 2015-02-19 13:21 +0000
          Re: sqlite3 and dates Ethan Furman <ethan@stoneleaf.us> - 2015-02-18 14:52 -0800
          'Lite' Databases (Re: sqlite3 and dates) memilanuk <memilanuk@gmail.com> - 2015-02-18 15:32 -0800
            Re: 'Lite' Databases (Re: sqlite3 and dates) Mario Figueiredo <marfig@gmail.com> - 2015-02-19 01:08 +0100
              Re: 'Lite' Databases (Re: sqlite3 and dates) Chris Angelico <rosuav@gmail.com> - 2015-02-19 11:42 +1100
                Re: 'Lite' Databases (Re: sqlite3 and dates) Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-02-19 13:13 +1100
                  Re: 'Lite' Databases (Re: sqlite3 and dates) Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-02-19 03:43 +0000
                    Re: 'Lite' Databases (Re: sqlite3 and dates) Mario Figueiredo <marfig@gmail.com> - 2015-02-19 08:49 +0100
                  Re: 'Lite' Databases (Re: sqlite3 and dates) rurpy@yahoo.com - 2015-02-18 20:10 -0800
                    Re: 'Lite' Databases (Re: sqlite3 and dates) Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-02-19 18:07 +1100
                      Re: 'Lite' Databases (Re: sqlite3 and dates) Chris Angelico <rosuav@gmail.com> - 2015-02-19 18:23 +1100
                        Re: 'Lite' Databases (Re: sqlite3 and dates) rurpy@yahoo.com - 2015-02-19 12:26 -0800
                          Re: 'Lite' Databases (Re: sqlite3 and dates) Chris Angelico <rosuav@gmail.com> - 2015-02-20 07:47 +1100
                            Re: 'Lite' Databases (Re: sqlite3 and dates) rurpy@yahoo.com - 2015-02-19 20:20 -0800
                              Re: 'Lite' Databases (Re: sqlite3 and dates) Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2015-02-20 09:16 -0500
                              Re: 'Lite' Databases (Re: sqlite3 and dates) Sibylle Koczian <nulla.epistola@web.de> - 2015-02-21 11:44 +0100
                              Re: 'Lite' Databases (Re: sqlite3 and dates) Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2015-02-21 12:54 -0500
                          Re: 'Lite' Databases (Re: sqlite3 and dates) Mario Figueiredo <marfig@gmail.com> - 2015-02-19 22:23 +0100
                            Re: 'Lite' Databases (Re: sqlite3 and dates) rurpy@yahoo.com - 2015-02-19 20:27 -0800
                      Re: 'Lite' Databases (Re: sqlite3 and dates) rurpy@yahoo.com - 2015-02-19 12:20 -0800
              Re: 'Lite' Databases (Re: sqlite3 and dates) rurpy@yahoo.com - 2015-02-18 20:05 -0800
                Re: 'Lite' Databases (Re: sqlite3 and dates) Tim Chase <python.list@tim.thechases.com> - 2015-02-19 08:21 -0600
              Re: 'Lite' Databases (Re: sqlite3 and dates) Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2015-02-19 18:22 +1300
                Re: 'Lite' Databases (Re: sqlite3 and dates) Mario Figueiredo <marfig@gmail.com> - 2015-02-19 08:33 +0100
              Re: 'Lite' Databases (Re: sqlite3 and dates) Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-02-19 05:32 +0000
              Re: 'Lite' Databases (Re: sqlite3 and dates) Tim Chase <python.list@tim.thechases.com> - 2015-02-19 08:17 -0600
              Re: 'Lite' Databases (Re: sqlite3 and dates) Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-02-19 15:04 +0000
              Re: 'Lite' Databases (Re: sqlite3 and dates) Chris Angelico <rosuav@gmail.com> - 2015-02-20 02:19 +1100
              Re: 'Lite' Databases (Re: sqlite3 and dates) Tim Chase <python.list@tim.thechases.com> - 2015-02-19 10:03 -0600
                Re: 'Lite' Databases (Re: sqlite3 and dates) rurpy@yahoo.com - 2015-02-19 11:45 -0800
          Re: 'Lite' Databases (Re: sqlite3 and dates) Ben Finney <ben+python@benfinney.id.au> - 2015-02-19 11:03 +1100
            Re: 'Lite' Databases (Re: sqlite3 and dates) Paul Rubin <no.email@nospam.invalid> - 2015-02-20 13:17 -0800
              Re: 'Lite' Databases (Re: sqlite3 and dates) Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-02-20 21:44 +0000
              Re: 'Lite' Databases (Re: sqlite3 and dates) Ethan Furman <ethan@stoneleaf.us> - 2015-02-20 14:10 -0800
              Re: 'Lite' Databases (Re: sqlite3 and dates) Chris Angelico <rosuav@gmail.com> - 2015-02-21 12:24 +1100
              Re: 'Lite' Databases Ben Finney <ben+python@benfinney.id.au> - 2015-02-21 14:13 +1100
              Re: 'Lite' Databases (Re: sqlite3 and dates) Tim Chase <python.list@tim.thechases.com> - 2015-02-20 15:31 -0600
              Re: 'Lite' Databases Chris Angelico <rosuav@gmail.com> - 2015-02-21 16:39 +1100
              Re: 'Lite' Databases (Re: sqlite3 and dates) Ned Deily <nad@acm.org> - 2015-02-20 22:22 -0800
                Re: 'Lite' Databases (Re: sqlite3 and dates) Paul Rubin <no.email@nospam.invalid> - 2015-02-20 22:42 -0800
                  Re: 'Lite' Databases (Re: sqlite3 and dates) Ned Deily <nad@acm.org> - 2015-02-21 00:17 -0800
                    Re: 'Lite' Databases (Re: sqlite3 and dates) Paul Rubin <no.email@nospam.invalid> - 2015-02-21 00:32 -0800
              Re: 'Lite' Databases (Re: sqlite3 and dates) "Eric S. Johansson" <esj@harvee.org> - 2015-02-21 14:27 -0500
          Re: 'Lite' Databases (Re: sqlite3 and dates) memilanuk <memilanuk@gmail.com> - 2015-02-18 19:33 -0800
          Re: 'Lite' Databases (Re: sqlite3 and dates) Chris Angelico <rosuav@gmail.com> - 2015-02-19 15:01 +1100
          Re: 'Lite' Databases (Re: sqlite3 and dates) Ben Finney <ben+python@benfinney.id.au> - 2015-02-19 15:09 +1100
            Re: 'Lite' Databases (Re: sqlite3 and dates) rurpy@yahoo.com - 2015-02-18 20:26 -0800
            Re: 'Lite' Databases (Re: sqlite3 and dates) Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-02-19 18:23 +1100
          When to use SQLite3 [was Re: 'Lite' Databases (Re: sqlite3 and dates)] Ethan Furman <ethan@stoneleaf.us> - 2015-02-18 20:15 -0800
            Re: When to use SQLite3 [was Re: 'Lite' Databases (Re: sqlite3 and dates)] Steve Hayes <hayesstw@telkomsa.net> - 2015-02-19 06:59 +0200
              Re: When to use SQLite3 [was Re: 'Lite' Databases (Re: sqlite3 and dates)] Ethan Furman <ethan@stoneleaf.us> - 2015-02-18 21:07 -0800
          Re: 'Lite' Databases (Re: sqlite3 and dates) memilanuk <memilanuk@gmail.com> - 2015-02-18 20:29 -0800
          Re: 'Lite' Databases (Re: sqlite3 and dates) Ben Finney <ben+python@benfinney.id.au> - 2015-02-19 15:36 +1100
          Re: 'Lite' Databases (Re: sqlite3 and dates) memilanuk <memilanuk@gmail.com> - 2015-02-18 20:57 -0800
          Re: 'Lite' Databases (Re: sqlite3 and dates) Ben Finney <ben+python@benfinney.id.au> - 2015-02-19 16:16 +1100
          Re: 'Lite' Databases (Re: sqlite3 and dates) memilanuk <memilanuk@gmail.com> - 2015-02-18 21:26 -0800
          Re: 'Lite' Databases (Re: sqlite3 and dates) Ethan Furman <ethan@stoneleaf.us> - 2015-02-18 21:37 -0800
            Re: 'Lite' Databases (Re: sqlite3 and dates) rurpy@yahoo.com - 2015-02-19 13:17 -0800
        Re: sqlite3 and dates Steve Hayes <hayesstw@telkomsa.net> - 2015-02-19 04:48 +0200
          Re: sqlite3 and dates Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-02-19 03:34 +0000
      Re: sqlite3 and dates Ben Finney <ben+python@benfinney.id.au> - 2015-02-19 07:14 +1100
        Re: sqlite3 and dates rurpy@yahoo.com - 2015-02-18 14:13 -0800
          Re: sqlite3 and dates Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-02-19 10:07 +1100
            Re: sqlite3 and dates rurpy@yahoo.com - 2015-02-18 20:08 -0800

Page 1 of 4  [1] 2 3 4  Next page →

#85771 — Re: sqlite3 and dates

On Wed, Feb 18, 2015 at 5:19 PM, Frank Millman <frank@chagford.com> wrote:
> However, the following does not return a date object -
>
>>>> cur.execute('SELECT CAST(? AS DATE)', ('2015-03-31',))
> <sqlite3.Cursor object at 0x00FE9BE0>
>>>> cur.fetchone()
> (2015,)
>>>>
>
> I don't know how easy this would be to implement, but it would be nice if it
> could be made to work.

Heh! Looks like the date is implemented as a slightly magical integer,
so "cast to date" becomes "cast to integer" and you just get back
2015. Could be really easy to fix, could be nigh impossible... but
sure, that seems a reasonable thing to ask for. Worst case, you get
told it's not practical.

But if you need more facilities than SQLite3 can offer, maybe it's
time to move up to a full database server, instead of local files.
Switching to PostgreSQL will give you all those kinds of features,
plus a lot of other things that I would have thought pretty basic -
like ALTER TABLE. It was quite a surprise to learn that SQLite3 didn't
support that.

ChrisA

[toc] | [next] | [standalone]

#85784

On 18.02.2015 08:05, Chris Angelico wrote:

> But if you need more facilities than SQLite3 can offer, maybe it's
> time to move up to a full database server, instead of local files.
> Switching to PostgreSQL will give you all those kinds of features,
> plus a lot of other things that I would have thought pretty basic -
> like ALTER TABLE. It was quite a surprise to learn that SQLite3 didn't
> support that.

I see you're running a lawnmower. Maybe you should switch to a combine
harvester. That'll get you extra features like a reciprocating knife
cutter bar. I was quite surprised that regular lawnmowers don't support
those.

Cheers,
Johannes

-- 
>> Wo hattest Du das Beben nochmal GENAU vorhergesagt?
> Zumindest nicht öffentlich!
Ah, der neueste und bis heute genialste Streich unsere großen
Kosmologen: Die Geheim-Vorhersage.
 - Karl Kaos über Rüdiger Thomas in dsa <hidbv3$om2$1@speranza.aioe.org>

[toc] | [prev] | [next] | [standalone]

#85785

On Wed, Feb 18, 2015 at 10:11 PM, Johannes Bauer <dfnsonfsduifb@gmx.de> wrote:
> On 18.02.2015 08:05, Chris Angelico wrote:
>
>> But if you need more facilities than SQLite3 can offer, maybe it's
>> time to move up to a full database server, instead of local files.
>> Switching to PostgreSQL will give you all those kinds of features,
>> plus a lot of other things that I would have thought pretty basic -
>> like ALTER TABLE. It was quite a surprise to learn that SQLite3 didn't
>> support that.
>
> I see you're running a lawnmower. Maybe you should switch to a combine
> harvester. That'll get you extra features like a reciprocating knife
> cutter bar. I was quite surprised that regular lawnmowers don't support
> those.

SQLite3 is fine for something that's basically just a more structured
version of a flat file. You assume that nobody but you has the file
open, and you manipulate it just the same as if it were a big fat blob
of JSON, but thanks to SQLite, you don't have to rewrite the whole
file every time you make a small change. That's fine. But it's the
wrong tool for any job involving multiple users over a network, and
quite probably the wrong tool for a lot of other jobs too. It's the
smallest-end piece of software that can truly be called a database. I
would consider it to be the wrong database for serious accounting
work, and that's based on the ranting of a majorly-annoyed accountant
who had to deal with issues in professional systems that had made
similar choices in back-end selection.

You're welcome to disagree, but since PostgreSQL doesn't cost any
money and (on Linux at least; can't speak for other platforms) doesn't
take significant effort to set up, I will continue to recommend it.

ChrisA

[toc] | [prev] | [next] | [standalone]

#85786

On 18.02.2015 12:21, Chris Angelico wrote:

> SQLite3 is fine for something that's basically just a more structured
> version of a flat file. You assume that nobody but you has the file
> open, and you manipulate it just the same as if it were a big fat blob
> of JSON, but thanks to SQLite, you don't have to rewrite the whole
> file every time you make a small change. That's fine. But it's the
> wrong tool for any job involving multiple users over a network, and
> quite probably the wrong tool for a lot of other jobs too.

Your assessment that some tools fit certain problems and don't fit
different problems is entirely correct. SQLite does the job that it is
supposed to do and it fills that nieche well.

> It's the
> smallest-end piece of software that can truly be called a database. I
> would consider it to be the wrong database for serious accounting
> work, and that's based on the ranting of a majorly-annoyed accountant
> who had to deal with issues in professional systems that had made
> similar choices in back-end selection.

It probably is the wrong database for serious accounting work, and it's
probably also the wrong database for doing multivariate statistical
analysis on sparse matrices that you store in tables.

You could similarly argue that a hammer is the wrong tool to drive in a
screw and you'd be correct in that assessment. But it's completely
besides the point.

SQLite and Postgres are so vastly different in their setup,
configuration, capabilities and requirements that the original developer
has to have done a MAJOR error in judgement so that a change from one to
the other would not be ill-advised.

> You're welcome to disagree, but since PostgreSQL doesn't cost any
> money and (on Linux at least; can't speak for other platforms) doesn't
> take significant effort to set up, I will continue to recommend it.

I work with Postgres on a professional, day-to-day basis. And while it's
free, it *does* take a significant effort to setup and it *does* take a
significant effort to maintain. Especially in comparison with something
like SQLite that literally has no setup at all.

PostgreSQL is great. It's an incredible database and that it's free is
amazing. But in very few settings will it be a replacement for SQLite.

Cheers,
Johannes


-- 
>> Wo hattest Du das Beben nochmal GENAU vorhergesagt?
> Zumindest nicht öffentlich!
Ah, der neueste und bis heute genialste Streich unsere großen
Kosmologen: Die Geheim-Vorhersage.
 - Karl Kaos über Rüdiger Thomas in dsa <hidbv3$om2$1@speranza.aioe.org>

[toc] | [prev] | [next] | [standalone]

#85789

On Wed, Feb 18, 2015 at 10:57 PM, Johannes Bauer <dfnsonfsduifb@gmx.de> wrote:
> SQLite and Postgres are so vastly different in their setup,
> configuration, capabilities and requirements that the original developer
> has to have done a MAJOR error in judgement so that a change from one to
> the other would not be ill-advised.

On Wed, Feb 18, 2015 at 6:49 PM, Frank Millman <frank@chagford.com> wrote:
> My accounting software supports three databases - MS Sql Server, PostgreSQL,
> and sqlite3.

Johannes, are you saying that Frank made three major errors of judgement? :)

ChrisA

[toc] | [prev] | [next] | [standalone]

#85790

On 18.02.2015 13:14, Chris Angelico wrote:
> On Wed, Feb 18, 2015 at 10:57 PM, Johannes Bauer <dfnsonfsduifb@gmx.de> wrote:
>> SQLite and Postgres are so vastly different in their setup,
>> configuration, capabilities and requirements that the original developer
>> has to have done a MAJOR error in judgement so that a change from one to
>> the other would not be ill-advised.
> 
> On Wed, Feb 18, 2015 at 6:49 PM, Frank Millman <frank@chagford.com> wrote:
>> My accounting software supports three databases - MS Sql Server, PostgreSQL,
>> and sqlite3.
> 
> Johannes, are you saying that Frank made three major errors of judgement? :)

I'm totally pulling my fifth! :-P

Cheers,
Johannes

-- 
>> Wo hattest Du das Beben nochmal GENAU vorhergesagt?
> Zumindest nicht öffentlich!
Ah, der neueste und bis heute genialste Streich unsere großen
Kosmologen: Die Geheim-Vorhersage.
 - Karl Kaos über Rüdiger Thomas in dsa <hidbv3$om2$1@speranza.aioe.org>

[toc] | [prev] | [next] | [standalone]

#85843 — Not sqlite3 and dates

On Wed, 18 Feb 2015 23:14:32 +1100, Chris Angelico <rosuav@gmail.com>
wrote:

>On Wed, Feb 18, 2015 at 10:57 PM, Johannes Bauer <dfnsonfsduifb@gmx.de> wrote:
>> SQLite and Postgres are so vastly different in their setup,
>> configuration, capabilities and requirements that the original developer
>> has to have done a MAJOR error in judgement so that a change from one to
>> the other would not be ill-advised.
>
>On Wed, Feb 18, 2015 at 6:49 PM, Frank Millman <frank@chagford.com> wrote:
>> My accounting software supports three databases - MS Sql Server, PostgreSQL,
>> and sqlite3.
>
>Johannes, are you saying that Frank made three major errors of judgement? :)

No, ChrisA did, in answering questions that no one was asking, and
changing the subject of the thread without changing the subject line. 
-- 
Steve Hayes from Tshwane, South Africa
Web:  http://www.khanya.org.za/stevesig.htm
Blog: http://khanya.wordpress.com
E-mail - see web page, or parse: shayes at dunelm full stop org full stop uk

[toc] | [prev] | [next] | [standalone]

#85900

On 2015-02-18, Johannes Bauer wrote:

> On 18.02.2015 12:21, Chris Angelico wrote:
>
>> SQLite3 is fine for something that's basically just a more structured
>> version of a flat file. You assume that nobody but you has the file
>> open, and you manipulate it just the same as if it were a big fat blob
>> of JSON, but thanks to SQLite, you don't have to rewrite the whole
>> file every time you make a small change. That's fine. But it's the
>> wrong tool for any job involving multiple users over a network, and
>> quite probably the wrong tool for a lot of other jobs too.
>
> Your assessment that some tools fit certain problems and don't fit
> different problems is entirely correct. SQLite does the job that it is
> supposed to do and it fills that nieche well.
>
>> It's the
>> smallest-end piece of software that can truly be called a database. I
>> would consider it to be the wrong database for serious accounting
>> work, and that's based on the ranting of a majorly-annoyed accountant
>> who had to deal with issues in professional systems that had made
>> similar choices in back-end selection.
>
> It probably is the wrong database for serious accounting work, and it's
> probably also the wrong database for doing multivariate statistical
> analysis on sparse matrices that you store in tables.
>
> You could similarly argue that a hammer is the wrong tool to drive in a
> screw and you'd be correct in that assessment. But it's completely
> besides the point.

"If your only tool is a hammer, every problem looks like a nail."
;-)


-- 
In the 1970s, people began receiving utility bills for
-£999,999,996.32 and it became harder to sustain the 
myth of the infallible electronic brain. (Verity Stob)

[toc] | [prev] | [next] | [standalone]

#85826

On 02/18/2015 04:21 AM, Chris Angelico wrote:
> On Wed, Feb 18, 2015 at 10:11 PM, Johannes Bauer <dfnsonfsduifb@gmx.de> wrote:
>> On 18.02.2015 08:05, Chris Angelico wrote:
>>
>>> But if you need more facilities than SQLite3 can offer, maybe it's
>>> time to move up to a full database server, instead of local files.
>>> Switching to PostgreSQL will give you all those kinds of features,
>>> plus a lot of other things that I would have thought pretty basic -
>>> like ALTER TABLE. It was quite a surprise to learn that SQLite3 didn't
>>> support that.
>>
>> I see you're running a lawnmower. Maybe you should switch to a combine
>> harvester. That'll get you extra features like a reciprocating knife
>> cutter bar. I was quite surprised that regular lawnmowers don't support
>> those.
> 
> SQLite3 is fine for something that's basically just a more structured
> version of a flat file. You assume that nobody but you has the file
> open, and you manipulate it just the same as if it were a big fat blob
> of JSON, but thanks to SQLite, you don't have to rewrite the whole
> file every time you make a small change. That's fine.

That's bullshit.  Sqlite offers a lot more than that including
a SQL interface, transactions, referential integrity, constraints 
indexes, triggers and other general relational database features.  

That you would equate that to a JSON blob would indicate either 
a profound ignorance about Sqlite or (more likely) a need to
defend your preference with complete disregard of fact. 

> But it's the
> wrong tool for any job involving multiple users over a network, and
> quite probably the wrong tool for a lot of other jobs too. 

Nobody disputes that nor was that the point.  The point was 
that there are many applications that can benefit from use 
of a database that are NOT distributed multi-user, muilti-tier
applications.  For many of that very large class of applications 
Sqlite is a good (and preferable to Postgresql) solution.

> It's the
> smallest-end piece of software that can truly be called a database. I
> would consider it to be the wrong database for serious accounting
> work, and that's based on the ranting of a majorly-annoyed accountant
> who had to deal with issues in professional systems that had made
> similar choices in back-end selection.

I consider the program I use for my personal accounting program 
to be for very serious use since errors could have very grave
consequences for me.  But a multi-user client-server database 
is emphatically not needed by it.

And I'm sure you're aware that "not for serious use" is a common 
way that C and Java programmers dismiss Python?  So maybe you 
should try a little harder to come up with real arguments and 
not rely on cheap and meaningless labels.

> You're welcome to disagree, but since PostgreSQL doesn't cost any
> money and (on Linux at least; can't speak for other platforms) doesn't
> take significant effort to set up, I will continue to recommend it.

Postgresql costs a *lot* more -- in setup and on-going maintenance.
Not all (or even most) costs are the initial monetary purchase expense.

Its an unmoderated newsgroup so feel free to recommend what you
want.  But counter opinions should be aired so that others a
can judge for themselves whether your recommendations are based 
on facts or on your personal preferences.

[toc] | [prev] | [next] | [standalone]

#85828

On Thu, Feb 19, 2015 at 9:17 AM,  <rurpy@yahoo.com.dmarc.invalid> wrote:
>> SQLite3 is fine for something that's basically just a more structured
>> version of a flat file. You assume that nobody but you has the file
>> open, and you manipulate it just the same as if it were a big fat blob
>> of JSON, but thanks to SQLite, you don't have to rewrite the whole
>> file every time you make a small change. That's fine.
>
> That's bullshit.  Sqlite offers a lot more than that including
> a SQL interface, transactions, referential integrity, constraints
> indexes, triggers and other general relational database features.
>
> That you would equate that to a JSON blob would indicate either
> a profound ignorance about Sqlite or (more likely) a need to
> defend your preference with complete disregard of fact.

I didn't equate them. I said that SQLite3 is great if you look on it
as an upgrade over a JSON blob. Of course it offers more features than
that, and you don't need to swear at me to make your point.

But SQLite3 is *not* great if you look on it as a database engine
comparable with DB2, PostgreSQL, and even MySQL.

ChrisA

[toc] | [prev] | [next] | [standalone]

#85844 — Not sqlite3 and dates

On Thu, 19 Feb 2015 09:37:49 +1100, Chris Angelico <rosuav@gmail.com>
wrote:

>On Thu, Feb 19, 2015 at 9:17 AM,  <rurpy@yahoo.com.dmarc.invalid> wrote:
>>> SQLite3 is fine for something that's basically just a more structured
>>> version of a flat file. You assume that nobody but you has the file
>>> open, and you manipulate it just the same as if it were a big fat blob
>>> of JSON, but thanks to SQLite, you don't have to rewrite the whole
>>> file every time you make a small change. That's fine.
>>
>> That's bullshit.  Sqlite offers a lot more than that including
>> a SQL interface, transactions, referential integrity, constraints
>> indexes, triggers and other general relational database features.
>>
>> That you would equate that to a JSON blob would indicate either
>> a profound ignorance about Sqlite or (more likely) a need to
>> defend your preference with complete disregard of fact.
>
>I didn't equate them. I said that SQLite3 is great if you look on it
>as an upgrade over a JSON blob. Of course it offers more features than
>that, and you don't need to swear at me to make your point.
>
>But SQLite3 is *not* great if you look on it as a database engine
>comparable with DB2, PostgreSQL, and even MySQL.

And how does that answer the OP's question?
-- 
Steve Hayes from Tshwane, South Africa
Web:  http://www.khanya.org.za/stevesig.htm
Blog: http://khanya.wordpress.com
E-mail - see web page, or parse: shayes at dunelm full stop org full stop uk

[toc] | [prev] | [next] | [standalone]

#85901

On 2015-02-18, Chris Angelico wrote:

> On Thu, Feb 19, 2015 at 9:17 AM,  <rurpy@yahoo.com.dmarc.invalid> wrote:
>>> SQLite3 is fine for something that's basically just a more structured
>>> version of a flat file. You assume that nobody but you has the file
>>> open, and you manipulate it just the same as if it were a big fat blob
>>> of JSON, but thanks to SQLite, you don't have to rewrite the whole
>>> file every time you make a small change. That's fine.
>>
>> That's bullshit.  Sqlite offers a lot more than that including
>> a SQL interface, transactions, referential integrity, constraints
>> indexes, triggers and other general relational database features.
>>
>> That you would equate that to a JSON blob would indicate either
>> a profound ignorance about Sqlite or (more likely) a need to
>> defend your preference with complete disregard of fact.
>
> I didn't equate them. I said that SQLite3 is great if you look on it
> as an upgrade over a JSON blob. Of course it offers more features than
> that, and you don't need to swear at me to make your point.
>
> But SQLite3 is *not* great if you look on it as a database engine
> comparable with DB2, PostgreSQL, and even MySQL.

I certainly agree with that bit, but in my own code I can almost never
justify the hassle (set-up, security considerations, &c.) of using a
database server.  TBH, one reason I like SQLite3 is that I can easily
move the data file around in the filesystem or between machies.


-- 
"It is the role of librarians to keep government running in difficult
times," replied Dramoren.  "Librarians are the last line of defence
against chaos."                                       (McMullen 2001)

[toc] | [prev] | [next] | [standalone]

#85829

[Multipart message — attachments visible in raw view] — view raw

On Thu, Feb 19, 2015 at 9:17 AM,  rurpy wrote:
> That you would equate that to a JSON blob [...]

Chris wrote:
> I didn't equate them.

>> Chris wrote earlier:
>>> and you manipulate it just the same as if it were a big fat blob
>>> of JSON

That sure sounds like equating.

Chris also wrote:
> But SQLite3 is *not* great if you look on it as a database engine
> comparable with DB2, PostgreSQL, and even MySQL.

Sure, the LITE in SQLite means you don't get some things.  There is still a huge amount of software that doesn't need
concurrency and can benefit from it.

Having installed Postgres I can say there is definitely a cost to install it, use it, maintain it, etc... especially if
you aren't steeped in it and have to look things up every time you have to make a change (how do I add a user again?).

I think the general advice should be:  if you are writing a single-user application that happens to need SQL services,
check out SQLite; if you are writing a multi-user or concurrent SQL application, check out Postgres.

--
~Ethan~

[toc] | [prev] | [next] | [standalone]

#85834 — 'Lite' Databases (Re: sqlite3 and dates)

On 02/18/2015 02:52 PM, Ethan Furman wrote:

> Chris also wrote:
>> But SQLite3 is *not* great if you look on it as a database engine
>> comparable with DB2, PostgreSQL, and even MySQL.
>
> Sure, the LITE in SQLite means you don't get some things.  There is still a huge amount of software that doesn't need
> concurrency and can benefit from it.
>
> Having installed Postgres I can say there is definitely a cost to install it, use it, maintain it, etc... especially if
> you aren't steeped in it and have to look things up every time you have to make a change (how do I add a user again?).
>
> I think the general advice should be:  if you are writing a single-user application that happens to need SQL services,
> check out SQLite; if you are writing a multi-user or concurrent SQL application, check out Postgres.

Okay... this might be a question with a blindingly obvious answer, but I 
haven't seen any recommendations otherwise so I'll ask anyway ;)

Is there anything *good* that sits in between the two extremes of SQLite 
and PostgreSQL?

I've tinkered with MySQL years ago (in conjunction with PHP) and was a 
little unhappy with some of the things it either didn't implement fully 
(foreign keys) or silently ignored (check constraints).  PostgreSQL, to 
me, is orders of magnitude harder to set up and maintain, though.  And 
then there is SQLite, which does 99% of what I want it to do other than 
network use.  I see other DB names such as DB2, Oracle, MS SQL Server, 
etc. out there but the only other 'free' one seems to be Firebird?  Is 
that really the only other contender?  Is there nothing that amounts to 
a 'PostgreSQLite'?


-- 
Shiny!  Let's be bad guys.

Reach me @ memilanuk (at) gmail dot com

[toc] | [prev] | [next] | [standalone]

#85836 — Re: 'Lite' Databases (Re: sqlite3 and dates)

On Wed, 18 Feb 2015 15:32:36 -0800, memilanuk <memilanuk@gmail.com>
wrote:

>
>Is there anything *good* that sits in between the two extremes of SQLite 
>and PostgreSQL?
>
>I've tinkered with MySQL years ago (in conjunction with PHP) and was a 
>little unhappy with some of the things

MariaDB is backwards compatible with MySQL and may answer some of the
shortcomings. It's a much stronger RDBM in my opinion than MySQL and
offers enterprise level features at cost 0.


> PostgreSQL, to me, is orders of magnitude harder to set up and
> maintain, though.

PostgreSQL grows on you. It takes time to mature into a love
relationship, like a complicated girlfriend (or boyfriend, whatever
floats your boat). But once that relationship grows, you will want to
marry with it, have little postgre kids and grow old with it. No other
database stands a chance from that moment on.

It's just too powerful and too feature rich, to ignore. Only Oracle
stands a chance against it, in my humble opinion.

And postgre isn't really that hard to setup and maintain. In fact,
maintenance can be largely scriptable and 'croned' because the postgre
server is so damn stable. Once you familiarize yourself with the
process, you just realize it was easy all the time after all.

I usually think of my relationship with postgre as similar to what I
experienced with Git. At first I was just dumbstruck by the whole
thing and my first reaction was to ignore it and just do version
control as I knew with the tools I knew. But once my brain clicked
into 'Git mode' and I realized its philosophy and its processes, I
immediately recognized the benefits and understood why everyone was
telling me Git was easy to use and highly useful.

>then there is SQLite, which does 99% of what I want it to do other than 
>network use.

SQLite misses some important features that makes it better suited as a
simple datastore, not much unlike shelve. And network use is not one
of them, since you can actually implement concurrent sqlite access by
coding an intermediate layer. Assuming of course we are talking about
a small number of concurrent users.

Stored procedures is perhaps the most obvious missing feature.
Contrary to an opinion I read on the thread that spawned this one, you
really should thrive to put the business logic into the database as
this permits great simplification of your code and much better
adaptability to new requirements. SQLite IS a database. And wants to
be used as a database. So despite agreeing SPs would increase SQLite
footprint, it's undeniable they could be put to good use. Admittedly
these too can be implemented through an intermediate layer. But are
much more complex to code.

Parameterized queries is just a pet peeve of mine that I wish to
include here. SQLite misses it and I miss the fact SQLite misses it.
The less SQL one needs to write in their code, the happier one should
be.

[toc] | [prev] | [next] | [standalone]

#85839 — Re: 'Lite' Databases (Re: sqlite3 and dates)

On Thu, Feb 19, 2015 at 11:08 AM, Mario Figueiredo <marfig@gmail.com> wrote:
> I usually think of my relationship with postgre as similar to what I
> experienced with Git. At first I was just dumbstruck by the whole
> thing and my first reaction was to ignore it and just do version
> control as I knew with the tools I knew. But once my brain clicked
> into 'Git mode' and I realized its philosophy and its processes, I
> immediately recognized the benefits and understood why everyone was
> telling me Git was easy to use and highly useful.

(Side point: If you're going to treat PostgreSQL the way you'd treat a
girlfriend/boyfriend, you should probably be careful of how you
address him. "Postgres" or "PostgreSQL", but not usually "Postgre".)

This is a quite apt analogy. You have to get your head around some
fundamentals, but once you do, life becomes amazing.

>>then there is SQLite, which does 99% of what I want it to do other than
>>network use.
>
> SQLite misses some important features that makes it better suited as a
> simple datastore, not much unlike shelve. And network use is not one
> of them, since you can actually implement concurrent sqlite access by
> coding an intermediate layer. Assuming of course we are talking about
> a small number of concurrent users.

This is what I was saying: it's fine for purposes like Firefox's
bookmarks and settings and such (which I think was what it was
originally developed for?). Not so fine over a network.

Adding an intermediate layer is a lot more effort than you might
think. By the time you've gone there, you should be looking at
PostgreSQL anyway. I tried to bolt networking support onto a couple of
different databasing systems, back in the 90s, and it was faintly
ridiculous... I mean, it worked, but if I'd had today's Postgres, I
would never have done anything of the sort.

ChrisA

[toc] | [prev] | [next] | [standalone]

#85840 — Re: 'Lite' Databases (Re: sqlite3 and dates)

Chris Angelico wrote:

>> SQLite misses some important features that makes it better suited as a
>> simple datastore, not much unlike shelve. And network use is not one
>> of them, since you can actually implement concurrent sqlite access by
>> coding an intermediate layer. Assuming of course we are talking about
>> a small number of concurrent users.
> 
> This is what I was saying: it's fine for purposes like Firefox's
> bookmarks and settings and such (which I think was what it was
> originally developed for?). Not so fine over a network.

The sheer number of Firefox bugs related to its use of SQLite says 
different.

Once upon a time, Firefox's config, bookmarks, etc. were stored in plain 
text files. At worst they were HTML. You could trivially read them, copy 
them, restore them and even (if you were careful) edit them using the text 
editor of your choice. Many a time I was on one machine, wanted to know a 
bookmark from another machine, so I would ssh across to the other machine 
and run grep over the bookmark file.

No more. Firefox still keeps a bookmark HTML file, but it never seems to be 
synced with the actual bookmarks. Settings are stored in an opaque blob, 
rather than human-readable text, limiting what you can do with it. It's very 
nice that Firefox offers about:config but not so nice that you can't do the 
same thing without the GUI running.

If Firefox crashes, there are failure modes where it can no longer read your 
bookmarks, or keep history. I don't mean that history won't persist across 
restarts, I mean that *within a single session* it cannot remember what page 
you came from so you can hit the Back button and return to it. WTF? 

I swear, if not for the fact that every single other browser is worse, I 
would dump Firefox in a second.

I don't believe for a second that moving to SQlite has anything to do with 
performance, because reading and writing preference settings should be rare 
and far from a bottleneck. SQlite is simply fragile and unreliable over a 
network, and people using their home directory on a network drive are not 
that rare.


-- 
Steve

[toc] | [prev] | [next] | [standalone]

#85847 — Re: 'Lite' Databases (Re: sqlite3 and dates)

On 19/02/2015 02:13, Steven D'Aprano wrote:
> Chris Angelico wrote:
>
>>> SQLite misses some important features that makes it better suited as a
>>> simple datastore, not much unlike shelve. And network use is not one
>>> of them, since you can actually implement concurrent sqlite access by
>>> coding an intermediate layer. Assuming of course we are talking about
>>> a small number of concurrent users.
>>
>> This is what I was saying: it's fine for purposes like Firefox's
>> bookmarks and settings and such (which I think was what it was
>> originally developed for?). Not so fine over a network.
>
> The sheer number of Firefox bugs related to its use of SQLite says
> different.
>
> Once upon a time, Firefox's config, bookmarks, etc. were stored in plain
> text files. At worst they were HTML. You could trivially read them, copy
> them, restore them and even (if you were careful) edit them using the text
> editor of your choice. Many a time I was on one machine, wanted to know a
> bookmark from another machine, so I would ssh across to the other machine
> and run grep over the bookmark file.
>
> No more. Firefox still keeps a bookmark HTML file, but it never seems to be
> synced with the actual bookmarks. Settings are stored in an opaque blob,
> rather than human-readable text, limiting what you can do with it. It's very
> nice that Firefox offers about:config but not so nice that you can't do the
> same thing without the GUI running.
>
> If Firefox crashes, there are failure modes where it can no longer read your
> bookmarks, or keep history. I don't mean that history won't persist across
> restarts, I mean that *within a single session* it cannot remember what page
> you came from so you can hit the Back button and return to it. WTF?
>
> I swear, if not for the fact that every single other browser is worse, I
> would dump Firefox in a second.
>

After a wonderful relationship lasting many happy years I dumped Firefox 
a few weeks ago for Chrome.  A few anxious moments gave me pause for 
thought, but overall I'm happy to have changed.  However is anybody 
aware of a "new kid on the block" that could take over as I'd happily 
switch again?  Nothing has sprung out at me, hence the choice I made.

-- 
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence

[toc] | [prev] | [next] | [standalone]

#85877 — Re: 'Lite' Databases (Re: sqlite3 and dates)

On Thu, 19 Feb 2015 03:43:36 +0000, Mark Lawrence
<breamoreboy@yahoo.co.uk> wrote:
>After a wonderful relationship lasting many happy years I dumped Firefox 
>a few weeks ago for Chrome.  A few anxious moments gave me pause for 
>thought, but overall I'm happy to have changed.  However is anybody 
>aware of a "new kid on the block" that could take over as I'd happily 
>switch again?  Nothing has sprung out at me, hence the choice I made.

Despite being built on Chrome framework, Vivaldi seems like an
interesting option. Made by the original makers of Opera who have
grown annoyed at the direction their browser took.

When they opened Vivaldi beta to the public a few weeks ago, it gained
good  reviews a little all over the web.

https://vivaldi.com/

[toc] | [prev] | [next] | [standalone]

#85853 — Re: 'Lite' Databases (Re: sqlite3 and dates)

On 02/18/2015 07:13 PM, Steven D'Aprano wrote:> Chris Angelico wrote:
>>> SQLite misses some important features that makes it better suited as a
>>> simple datastore, not much unlike shelve. And network use is not one
>>> of them, since you can actually implement concurrent sqlite access by
>>> coding an intermediate layer. Assuming of course we are talking about
>>> a small number of concurrent users.
>>
>> This is what I was saying: it's fine for purposes like Firefox's
>> bookmarks and settings and such (which I think was what it was
>> originally developed for?). Not so fine over a network.
> 
> The sheer number of Firefox bugs related to its use of SQLite says
> different.
>
> Once upon a time, Firefox's config, bookmarks, etc. were stored in plain
> text files. At worst they were HTML. You could trivially read them, copy
> them, restore them and even (if you were careful) edit them using the text
> editor of your choice. Many a time I was on one machine, wanted to know a
> bookmark from another machine, so I would ssh across to the other machine
> and run grep over the bookmark file.

I agree, I prefer plain text files whenever practical.  But since 
the original discussion was about Sqlite vs Postgresql, not Sqlite
vs text files, shouldn't the question be: would Firefox be better 
if it required you to install and configure Postgreql instead of 
using Sqlite?

> No more. Firefox still keeps a bookmark HTML file, but it never seems to be
> synced with the actual bookmarks. Settings are stored in an opaque blob,
> rather than human-readable text, limiting what you can do with it. It's very
> nice that Firefox offers about:config but not so nice that you can't do the
> same thing without the GUI running.
> 
> If Firefox crashes, there are failure modes where it can no longer read your
> bookmarks, or keep history. I don't mean that history won't persist across
> restarts, I mean that *within a single session* it cannot remember what page
> you came from so you can hit the Back button and return to it. WTF?
> 
> I swear, if not for the fact that every single other browser is worse, I
> would dump Firefox in a second.
> 
> I don't believe for a second that moving to SQlite has anything to do with
> performance, because reading and writing preference settings should be rare
> and far from a bottleneck. SQlite is simply fragile and unreliable over a
> network, and people using their home directory on a network drive are not
> that rare.

I don't see any evidence that it is Sqlite that is the problem
as opposed to FF's use (or misuse) of it, or other problems that
are in FF and have nothing to do with Sqlite.  If Sqlite reliably 
implements ACID semantics as they claim, is certainly should be 
possible to make use of it without the problems you (and I too) 
see.  And there is no reason to believe the situation would be
any better with Postgresql.

[toc] | [prev] | [next] | [standalone]

Page 1 of 4  [1] 2 3 4  Next page →

Back to top | Article view | comp.lang.python

csiph-web