Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.python > #85771 > unrolled thread
| Started by | Chris Angelico <rosuav@gmail.com> |
|---|---|
| First post | 2015-02-18 18:05 +1100 |
| Last post | 2015-02-18 20:08 -0800 |
| Articles | 15 on this page of 75 — 18 participants |
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.
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 4 of 4 — ← Prev page 1 2 3 [4]
| From | Steve Hayes <hayesstw@telkomsa.net> |
|---|---|
| Date | 2015-02-19 06:59 +0200 |
| Subject | Re: When to use SQLite3 [was Re: 'Lite' Databases (Re: sqlite3 and dates)] |
| Message-ID | <m5raea10psqef7v74nvt81r4fafabugiqv@4ax.com> |
| In reply to | #85854 |
On Wed, 18 Feb 2015 20:15:30 -0800, Ethan Furman <ethan@stoneleaf.us> wrote: >At the risk of using actual data, I looked this up at http://www.sqlite.org/whentouse.html: > > >Checklist For Choosing The Right Database Engine Interesting. A couple of months ago I asked in comp.databases what the differences were between SQLite and MySQL, and I got a lot of uninformative gobbledegook. This was more informative. I would summarise it by saying if you want a multiuser database running on a network, use MySQL. If you want a standalone database on a single machine, use SQLite. -- 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]
| From | Ethan Furman <ethan@stoneleaf.us> |
|---|---|
| Date | 2015-02-18 21:07 -0800 |
| Subject | Re: When to use SQLite3 [was Re: 'Lite' Databases (Re: sqlite3 and dates)] |
| Message-ID | <mailman.18859.1424322477.18130.python-list@python.org> |
| In reply to | #85859 |
[Multipart message — attachments visible in raw view] — view raw
On 02/18/2015 08:59 PM, Steve Hayes wrote: > I would summarise it by saying [...] if you want a standalone database on > a single machine, use SQLite. It sounds like SQLite would also work fine if that single-machine scenario was a web-app with not-too-many users trying to write at once. -- ~Ethan~
[toc] | [prev] | [next] | [standalone]
| From | memilanuk <memilanuk@gmail.com> |
|---|---|
| Date | 2015-02-18 20:29 -0800 |
| Subject | Re: 'Lite' Databases (Re: sqlite3 and dates) |
| Message-ID | <mailman.18854.1424320189.18130.python-list@python.org> |
| In reply to | #85826 |
On 02/18/2015 08:09 PM, Ben Finney wrote: >> I have a hard time picturing that few people stressing a modern >> computer system enough to where SQLite couldn't keep up (thinking >> web-based interface using Flask or something similar). In the latter >> case, one of the over-arching priorities is that it be easily >> distributable, as in that people with relatively little knowledge of a >> database be able to set it up and run it. > > Set it up where? Are you hoping that a network-accessible service can be > set up without knowledge of the specific concurrent authenticated > networked access is needed in each installation? > They would need to be able to set up the application (and whatever database) on their laptop or PC, wherever that may be, and spend their time administering the event, not the database engine. Once its set, it shouldn't need any tending, or they are going to be SOL as I wouldn't be able to help them. It may be that Flask + SQLite will be enough; otherwise I foresee a disproportional amount of *my* time will be spent documenting and explaining how to set up and maintain a RDBMS on Windows, on a Mac, etc. Starting to wonder if a pre-configured VM appliance running in Virtualbox might be simpler for the end user to set up and run. -- Shiny! Let's be bad guys. Reach me @ memilanuk (at) gmail dot com
[toc] | [prev] | [next] | [standalone]
| From | Ben Finney <ben+python@benfinney.id.au> |
|---|---|
| Date | 2015-02-19 15:36 +1100 |
| Subject | Re: 'Lite' Databases (Re: sqlite3 and dates) |
| Message-ID | <mailman.18855.1424320566.18130.python-list@python.org> |
| In reply to | #85826 |
memilanuk <memilanuk@gmail.com> writes: > They would need to be able to set up the application (and whatever > database) on their laptop or PC, wherever that may be, and spend their > time administering the event, not the database engine. So, the database will only be accessed by exactly one application, on exactly the same machine and storage as the application? If so, you don't need concurrency. Otherwise, your database needs concurrency; and the person installing the database will need to make a lot of decisions about the specific network environment and devices to be allowed to access the database. But is this what you mean by your requirements not being met by SQLite? -- \ “Natural catastrophes are rare, but they come often enough. We | `\ need not force the hand of nature.” —Carl Sagan, _Cosmos_, 1980 | _o__) | Ben Finney
[toc] | [prev] | [next] | [standalone]
| From | memilanuk <memilanuk@gmail.com> |
|---|---|
| Date | 2015-02-18 20:57 -0800 |
| Subject | Re: 'Lite' Databases (Re: sqlite3 and dates) |
| Message-ID | <mailman.18857.1424321833.18130.python-list@python.org> |
| In reply to | #85826 |
On 02/18/2015 08:36 PM, Ben Finney wrote: > memilanuk <memilanuk@gmail.com> writes: > >> They would need to be able to set up the application (and whatever >> database) on their laptop or PC, wherever that may be, and spend their >> time administering the event, not the database engine. > > So, the database will only be accessed by exactly one application, on > exactly the same machine and storage as the application? If so, you > don't need concurrency. > > Otherwise, your database needs concurrency; and the person installing > the database will need to make a lot of decisions about the specific > network environment and devices to be allowed to access the database. > > But is this what you mean by your requirements not being met by SQLite? > In the past I've been waffling back and forth between a desktop client/server setup, or a web-based interface with everything on one computer. At this point I'm leaning toward the latter. -- Shiny! Let's be bad guys. Reach me @ memilanuk (at) gmail dot com
[toc] | [prev] | [next] | [standalone]
| From | Ben Finney <ben+python@benfinney.id.au> |
|---|---|
| Date | 2015-02-19 16:16 +1100 |
| Subject | Re: 'Lite' Databases (Re: sqlite3 and dates) |
| Message-ID | <mailman.18861.1424322980.18130.python-list@python.org> |
| In reply to | #85826 |
memilanuk <memilanuk@gmail.com> writes: > In the past I've been waffling back and forth between a desktop > client/server setup, or a web-based interface with everything on one > computer. At this point I'm leaning toward the latter. So, it's been many exchanges back and forth, and you still aren't telling us what specific needs you have that SQLite can't provide. At this point I'm just going to have to wait until you can lay out the specifics. -- \ “In economics, hope and faith coexist with great scientific | `\ pretension and also a deep desire for respectability.” —John | _o__) Kenneth Galbraith, 1970-06-07 | Ben Finney
[toc] | [prev] | [next] | [standalone]
| From | memilanuk <memilanuk@gmail.com> |
|---|---|
| Date | 2015-02-18 21:26 -0800 |
| Subject | Re: 'Lite' Databases (Re: sqlite3 and dates) |
| Message-ID | <mailman.18863.1424323606.18130.python-list@python.org> |
| In reply to | #85826 |
On 02/18/2015 09:16 PM, Ben Finney wrote: > memilanuk <memilanuk@gmail.com> writes: > >> In the past I've been waffling back and forth between a desktop >> client/server setup, or a web-based interface with everything on one >> computer. At this point I'm leaning toward the latter. > > So, it's been many exchanges back and forth, and you still aren't > telling us what specific needs you have that SQLite can't provide. At > this point I'm just going to have to wait until you can lay out the > specifics. > Okay, let me put it like this: if I set up a web interface using Flask for the front-end, and SQLite as the backend DB, running from a PC/laptop, with anywhere from 1 to 10 people doing data entry from other devices (laptops, desktops, tablets, etc.) at roughly the same time, is SQLite going to be 'concurrent' enough? -- Shiny! Let's be bad guys. Reach me @ memilanuk (at) gmail dot com
[toc] | [prev] | [next] | [standalone]
| From | Ethan Furman <ethan@stoneleaf.us> |
|---|---|
| Date | 2015-02-18 21:37 -0800 |
| Subject | Re: 'Lite' Databases (Re: sqlite3 and dates) |
| Message-ID | <mailman.18865.1424324301.18130.python-list@python.org> |
| In reply to | #85826 |
[Multipart message — attachments visible in raw view] — view raw
On 02/18/2015 09:26 PM, memilanuk wrote: > On 02/18/2015 09:16 PM, Ben Finney wrote: >> memilanuk <memilanuk@gmail.com> writes: >> >>> In the past I've been waffling back and forth between a desktop >>> client/server setup, or a web-based interface with everything on one >>> computer. At this point I'm leaning toward the latter. >> >> So, it's been many exchanges back and forth, and you still aren't >> telling us what specific needs you have that SQLite can't provide. At >> this point I'm just going to have to wait until you can lay out the >> specifics. >> > > Okay, let me put it like this: if I set up a web interface using Flask for the front-end, and SQLite as the backend DB, > running from a PC/laptop, with anywhere from 1 to 10 people doing data entry from other devices (laptops, desktops, > tablets, etc.) at roughly the same time, is SQLite going to be 'concurrent' enough? Well, having zero experience with SQLite, but having read the docs just today [snip snide remark] -- I think you'll be fine with SQLite under those conditions. :) -- ~Ethan~
[toc] | [prev] | [next] | [standalone]
| From | rurpy@yahoo.com |
|---|---|
| Date | 2015-02-19 13:17 -0800 |
| Subject | Re: 'Lite' Databases (Re: sqlite3 and dates) |
| Message-ID | <c4f52359-cdc6-4e9d-994e-1d9ead5c9d6a@googlegroups.com> |
| In reply to | #85869 |
On Wednesday, February 18, 2015 at 10:39:04 PM UTC-7, Ethan Furman wrote: > On 02/18/2015 09:26 PM, memilanuk wrote: > > On 02/18/2015 09:16 PM, Ben Finney wrote: > >> memilanuk <memilanuk@gmail.com> writes: > >> > >>> In the past I've been waffling back and forth between a desktop > >>> client/server setup, or a web-based interface with everything on one > >>> computer. At this point I'm leaning toward the latter. > >> > >> So, it's been many exchanges back and forth, and you still aren't > >> telling us what specific needs you have that SQLite can't provide. At > >> this point I'm just going to have to wait until you can lay out the > >> specifics. > >> > > > > Okay, let me put it like this: if I set up a web interface using Flask for the front-end, and SQLite as the backend DB, > > running from a PC/laptop, with anywhere from 1 to 10 people doing data entry from other devices (laptops, desktops, > > tablets, etc.) at roughly the same time, is SQLite going to be 'concurrent' enough? > > Well, having zero experience with SQLite, but having read the docs just today [snip snide remark] -- I think you'll be > fine with SQLite under those conditions. :) I too agree with this (with a similar caveat -- I've only used Sqlite for playing around and have no real experience using it in real-world applications). Another thing to keep in mind is if you do need find you need a more heavy duty backend, it will be easier to migrate from Sqlite to Postgresql (or whatever) [*] than to go the other way should you later find Postgresl too heavy-weight and costly. ---- [*] Unless you are very careful to use only features in Postgresql that you've determined can be easily migrated back to Sqlite. In practice very few people have the strength of character required to do this. :-)
[toc] | [prev] | [next] | [standalone]
| From | Steve Hayes <hayesstw@telkomsa.net> |
|---|---|
| Date | 2015-02-19 04:48 +0200 |
| Message-ID | <0ljaeal2vnr3gsuofo6gdetk2naf2oor0i@4ax.com> |
| In reply to | #85785 |
On Wed, 18 Feb 2015 22:21:35 +1100, Chris Angelico <rosuav@gmail.com> 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. 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. All of which has nothing, absolutely nothing, to do with the OP's question, which said nothing about number of users, but how the software handles dates. -- 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]
| From | Mark Lawrence <breamoreboy@yahoo.co.uk> |
|---|---|
| Date | 2015-02-19 03:34 +0000 |
| Message-ID | <mailman.18849.1424316907.18130.python-list@python.org> |
| In reply to | #85842 |
On 19/02/2015 02:48, Steve Hayes wrote: > > All of which has nothing, absolutely nothing, to do with the OP's > question, which said nothing about number of users, but how the > software handles dates. > Very true, but charging off like this at massive tangents is one of the reasons I love being here. -- 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]
| From | Ben Finney <ben+python@benfinney.id.au> |
|---|---|
| Date | 2015-02-19 07:14 +1100 |
| Message-ID | <mailman.18833.1424290450.18130.python-list@python.org> |
| In reply to | #85784 |
Johannes Bauer <dfnsonfsduifb@gmx.de> writes: > 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. Chris has pointed out one flaw in this analogy; I'll address another. A feature like ‘ALTER TABLE’ is not equivalent to a “reciprocating knife cutter bar”. I'm in agreement that it is a pretty basic SQL feature, and it doesn't appear to conflict with the narrow focus that we all agree is appropriate for SQLite. So you're mocking such an expectation as though it's expecting something wildly niche. I think you're propping up a straw man there; the expectation is quite simple and its absence from SQLite is astonishing. Your attempted mockery does not, IMO, hit home. -- \ “When we call others dogmatic, what we really object to is | `\ their holding dogmas that are different from our own.” —Charles | _o__) Issawi | Ben Finney
[toc] | [prev] | [next] | [standalone]
| From | rurpy@yahoo.com |
|---|---|
| Date | 2015-02-18 14:13 -0800 |
| Message-ID | <9799edb6-d01d-49c2-82a4-3d70d9ca2427@googlegroups.com> |
| In reply to | #85817 |
On 02/18/2015 01:14 PM, Ben Finney wrote: > Johannes Bauer <dfnsonfsduifb@gmx.de> writes: >> 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. > > Chris has pointed out one flaw in this analogy; I'll address another. > > A feature like 'ALTER TABLE' is not equivalent to a "reciprocating knife > cutter bar". I'm in agreement that it is a pretty basic SQL feature, and > it doesn't appear to conflict with the narrow focus that we all agree is > appropriate for SQLite. No, you and Chris are way off base and Johannes is correct. He was pointing out that there are many applications that can benefit from a database and a full-blown, bells and whistles solution like Postgresql is often overkill in that (very common) case. His analogy is quite apt and I wish I'd thought of it. > So you're mocking such an expectation as though it's expecting something > wildly niche. I think you're propping up a straw man there; the > expectation is quite simple and its absence from SQLite is astonishing. > Your attempted mockery does not, IMO, hit home. It has already been pointed out that Sqlite *does* have ALTER TABLE so you are either deliberately propagating false information or not paying attention. The only thing basic that a (claimed) relational database needs to support is the basic relational operations of which ALTER TABLE is not one, And if one insists on ALTER TALE the minimal requirement there is that it support RENAME. You and Chris are confusing convenience with necessity. The success and wide adoption of Sqlite is pretty clear evidence that there are many applications that can benefit from its use. Sqllite gets used because of a very important feature that Postgresql is missing -- the ability to embed a database in an application without requiring the installation and maintenance of an entire separate client-server infrastructure. If you are tempted to trivialize that feature you might want to scan the Postgresql mail list where that feature is regularly requested for Postgresql.
[toc] | [prev] | [next] | [standalone]
| From | Steven D'Aprano <steve+comp.lang.python@pearwood.info> |
|---|---|
| Date | 2015-02-19 10:07 +1100 |
| Message-ID | <54e51b29$0$12994$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #85825 |
rurpy@yahoo.com wrote: > On 02/18/2015 01:14 PM, Ben Finney wrote: >> Johannes Bauer <dfnsonfsduifb@gmx.de> writes: >>> 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. >> >> Chris has pointed out one flaw in this analogy; I'll address another. >> >> A feature like 'ALTER TABLE' is not equivalent to a "reciprocating knife >> cutter bar". I'm in agreement that it is a pretty basic SQL feature, and >> it doesn't appear to conflict with the narrow focus that we all agree is >> appropriate for SQLite. > > No, you and Chris are way off base and Johannes is correct. > He was pointing out that there are many applications that can > benefit from a database and a full-blown, bells and whistles > solution like Postgresql is often overkill in that (very common) > case. His analogy is quite apt and I wish I'd thought of it. I'm not seeing that at all. Chris explicitly proceeded his comments with the condition "if you need more facilities than SQLite3 can offer". Johannes' analogy ignores that and consequently mocks the very idea that anyone might need more than a regular lawmower -- even a farmer with a thousand acres of wheat to be harvested. Johannes' subsequent posts are more nuanced about Sqlite filling a niche and not being suitable for everything, but the analogy you're supporting doesn't. It's an amusing quip, quite funny, but like most quips, lacks nuance and misrepresents Chris' original position. Had Chris said, "SQlite? Pah, don't use that, Postgresql is a much better solution!", the combine harvester analogy would have been much more fair. But he didn't, so it isn't. But fair or not, it has inspired good discussion, so there is that in it's favour. -- Steven
[toc] | [prev] | [next] | [standalone]
| From | rurpy@yahoo.com |
|---|---|
| Date | 2015-02-18 20:08 -0800 |
| Message-ID | <5fff723b-c980-4746-bb24-f54a15392747@googlegroups.com> |
| In reply to | #85833 |
On 02/18/2015 04:07 PM, Steven D'Aprano wrote: > rurpy@yahoo.com wrote: >> On 02/18/2015 01:14 PM, Ben Finney wrote: >>> Johannes Bauer <dfnsonfsduifb@gmx.de> writes: >>>> 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. >>> >>> Chris has pointed out one flaw in this analogy; I'll address another. >>> >>> A feature like 'ALTER TABLE' is not equivalent to a "reciprocating knife >>> cutter bar". I'm in agreement that it is a pretty basic SQL feature, and >>> it doesn't appear to conflict with the narrow focus that we all agree is >>> appropriate for SQLite. >> >> No, you and Chris are way off base and Johannes is correct. >> He was pointing out that there are many applications that can >> benefit from a database and a full-blown, bells and whistles >> solution like Postgresql is often overkill in that (very common) >> case. His analogy is quite apt and I wish I'd thought of it. > > > I'm not seeing that at all. Chris explicitly proceeded his comments with the > condition "if you need more facilities than SQLite3 can offer". Right. And did so in a context where there the facility presumed not to be offered was getting a date back from Sqlite. Common sense should tell anyone that it is very improbable that there is no way to get a date out of a sqlite database. Chris' "solution" to that problem? Switch to Postgresql. That was the context for Johannes' analogy. > Johannes' > analogy ignores that and consequently mocks the very idea that anyone might > need more than a regular lawmower -- even a farmer with a thousand acres of > wheat to be harvested. The analogy works precisely because farmers with a thousand acres of wheat to be harvested need reciprocating knife cutter bars. In the same way people dealing with terabytes of data, concurrent updates, enterprise scale data and applications need a Postregsql. People mowing their lawns do not. People without needs for the things that client server database do well, whose problem is not immediately being able to figure out how to get a date, do not. (Did you really need that explained to you?) If you didn't interpret it the way I did (and the way I presume Johannes meant it) then, well, you didn't interpret it the same. Your interpretation (especially given your penchant for sophistry) are not my problem. I am quite happy to let anyone reading make their own evaluation. > Johannes' subsequent posts are more nuanced about Sqlite filling a niche and > not being suitable for everything, but the analogy you're supporting > doesn't. It's an amusing quip, quite funny, but like most quips, lacks > nuance and misrepresents Chris' original position. All analogies are imperfect and thus make easy targets. Shrug. >[...]
[toc] | [prev] | [standalone]
Page 4 of 4 — ← Prev page 1 2 3 [4]
Back to top | Article view | comp.lang.python
csiph-web