On Sun, Aug 16, 2015 at 7:55 PM, Alan Gauld wrote:
> On 17/08/15 00:52, boB Stepp wrote:
>
>>> sqlite3> .read populate_base_data.sql
>>
>>
>> I am assuming that the .read command would be replaced inside the
>> program by the cursor.executescript() method you mentioned? This will
>> be quite hand
On 17/08/15 00:52, boB Stepp wrote:
sqlite3> .read populate_base_data.sql
I am assuming that the .read command would be replaced inside the
program by the cursor.executescript() method you mentioned? This will
be quite handy, I think.
No.
The executescript() method *replaces* .read
.read is
On Sun, Aug 16, 2015 at 7:36 PM, Danny Yoo wrote:
> By the way, when you're unit testing with Sqlite, you might find it
> convenient to use the ":memory:" option, which keeps the database in
> RAM rather than on disk. That should make the "setup" and "tear-down"
> of the testing environment easi
Hi Bob,
By the way, when you're unit testing with Sqlite, you might find it
convenient to use the ":memory:" option, which keeps the database in
RAM rather than on disk. That should make the "setup" and "tear-down"
of the testing environment easier to maintain.
The principle is similar to that o
On Sun, Aug 16, 2015 at 6:04 PM, Alan Gauld wrote:
> On 16/08/15 23:29, boB Stepp wrote:
>
>> http://www.sqlite.org/download.html
>
>
> You definitely want this.
> You treat it like the >>> prompt in Pyython.
I had just finished installing and testing the installation just
before your email arriv
On 16/08/15 23:29, boB Stepp wrote:
http://www.sqlite.org/download.html
You definitely want this.
You treat it like the >>> prompt in Pyython.
A place to try out SQL queries before you put
them into your Python code. Also you can write
long sql code in a .sql filer and read them
into the inte
On Sun, Aug 16, 2015 at 4:03 AM, Steven D'Aprano wrote:
> On Sun, Aug 16, 2015 at 01:18:06AM -0500, boB Stepp wrote:
>> 1) It would seem that I need to install a stand-alone version of
>> SQLite, so that I can create this test db. Either that or write a
>> separate Python program whose sole purp
On 16/08/15 09:10, Ben Finney wrote:
So that points to a need for better design: Don't directly issue
arbitrary SQL queries in code which implements higher-level features.
Instead, define a much more specific interface between your feature code
and the lower-level code that interacts with the dat
On Sun, Aug 16, 2015 at 01:18:06AM -0500, boB Stepp wrote:
> Being committed to TDD for this project, I am not yet ready to write
> code till I figure out how to write the tests. It occurs to me that
> writing tests for code that interacts with the SQLite db may be
> non-trivial (At least for me!)
boB Stepp writes:
> Being committed to TDD for this project, I am not yet ready to write
> code till I figure out how to write the tests. It occurs to me that
> writing tests for code that interacts with the SQLite db may be
> non-trivial (At least for me!).
That's correct.
One of the primary b
On 16/08/15 07:18, boB Stepp wrote:
tonight, it appears that I need to create a test SQLite db. I don't
see any other way that I can test such code without having a db to
test against.
Correct. And it is a non trivial task but immensely useful since you can
populate it with sample data repre
Being committed to TDD for this project, I am not yet ready to write
code till I figure out how to write the tests. It occurs to me that
writing tests for code that interacts with the SQLite db may be
non-trivial (At least for me!). After doing some online research
tonight, it appears that I need
12 matches
Mail list logo
