So in the end it boils down to:
What you want the db to hold?
When do you need the db to hold it?
And...
When and where is it necessary to access it by the user?
Ah! Not an algorithm.
Many paths, same destination...grasshoppa.
___
Tutor maillist
On Tue, Dec 28, 2010 at 9:18 PM, David Hutto wrote:
> But in the case you need the db constantly open(such as tracking
> something, where you update the db
This assumes you don't connect directly to, but update from, for data
analysis, not real time tracking.
through some other offsite db),
> th
But in the case you need the db constantly open(such as tracking
something, where you update the db through some other offsite db),
then just committing the current would be suggestible(in my opinion),
and keeping the update live to check periodically for changes in the
timestamps of data from the
>
> > But to be sure, it is perfectly safe and valid to open the database on
> program startup, commit changes during the process and close it
> on exit (or unhandled exception)?
As long as it makes sense to do so, yes. There's no point having an open
connection to a database if there doesn't ne
On 26-12-10 19:31, Noah Hall wrote:
>Which is suggestible just in case the app or program crashes
during use.
(To O.P)
Indeed, though in such cases you must rely on your programmers
instinct to make the right decision - what applies for certain
instances of an application doesn't alwa
>
> >Which is suggestible just in case the app or program crashes during use.
>
(To O.P)
Indeed, though in such cases you must rely on your programmers instinct to
make the right decision - what applies for certain instances of an
application doesn't always conform with what applies for other inst
Unless intermittent
> saves are necessary within the app loop.
Which is suggestible just in case the app or program crashes during use.
___
Tutor maillist - Tutor@python.org
To unsubscribe or change subscription options:
http://mail.python.org/mailman/
On Sun, Dec 26, 2010 at 11:16 AM, Noah Hall wrote:
> As a rule, I tend to open and close a connection based on what I'm doing
> with the database.
I +1 that. Usually if I open the db in a function, I commit and close.
If it's in an app, for me personally, that should be the only place it
takes pl
As a rule, I tend to open and close a connection based on what I'm doing
with the database. If I were to directly run a series of queries one after
another, I would keep it open until a change in interface (referring to
changes in objects, both masters and slaves).
Also, you can perform any query t
Just for future reference, when it's part of the python standard
library, always go to the docs for the full functions and methods
available.
http://docs.python.org/library/sqlite3.html
It can make the usage a lot easier.
___
Tutor maillist - Tutor@py
You can call the commit() method of the connection object to ensure that any
changes are saved to disk, but it's strictly optional. Closely/reopening is
not necessary.
Cheers
On Sunday 26 December 2010, Timo wrote:
> Hello, I use SQLite in my application as database, but I think I'm doing
> s
Hello, I use SQLite in my application as database, but I think I'm doing
something wrong.
Currently, I open a connection and cursor object every time I do an
operation (insert, select, update, ...) and close it afterwards. Now I was
wondering if it wouldn't be better to open the connection if my a
12 matches
Mail list logo
