On Wed, Sep 13, 2017 at 11:33 PM, Mark Lawrence via Tutor
wrote:
> SQLAlchemy isn't the only Python ORM of course. There is a useful little
> article about ORMs and their availability here
> https://www.fullstackpython.com/object-relational-mappers-orms.html. A more
>
On Thu, Sep 14, 2017 at 2:06 AM, Peter Otten <__pete...@web.de> wrote:
> That's the "Law of leaky abstractions",
> https://www.joelonsoftware.com/2002/11/11/the-law-of-leaky-abstractions/
Thanks for the link to this article. I really enjoyed reading it. In
fact, so far every article I have read
On 14Sep2017 09:15, Alan Gauld wrote:
On 14/09/17 04:11, boB Stepp wrote:
SELECT some, fields (never *)
Why no "*"? Does this open up a security vulnerability?
Not so much security as resilience to change.
If you use * and the data schema changes
On 14/09/17 04:40, boB Stepp wrote:
>> mapping your logic layer object models to underlying
>> data tables.
>
> My initial thoughts here are that typically a particular class would
> map to a particular table and that each object instance would
> correspond to a row in said table. Is this
On 14/09/17 04:11, boB Stepp wrote:
>> SELECT some, fields (never *)
>
> Why no "*"? Does this open up a security vulnerability?
Not so much security as resilience to change.
If you use * and the data schema changes to include extra
fields then your * query returns the extra
On 14/09/2017 00:51, Cameron Simpson wrote:
Secondly, there's SQLAlchemy. It knows the dialects and asks you to
write "native" looking python syntax for selects etc. So stuff like:
db_conn.select(t.col1 == 9 and t.col2 == 10)
where "t" is a "table" object it has handed you. I believe
boB Stepp wrote:
>> at some point you will need to write database specific SQL or delegate
>> that task to a library -- sqlalchemy was already mentioned. I suspect
>> that you will then end up learning both the SQL dialects and the ORM
>> API...
>
> I maybe did not realize the full import of
On 12Sep2017 14:05, boB Stepp wrote:
As I continue to read about SQL, one thing jumps out: There are many
differences between how SQL statements are implemented among the
different database products. Even for relatively simple,
straightforward things like field
I forgot one other thing you mentioned that I had a question about.
On Wed, Sep 13, 2017 at 2:41 AM, Alan Gauld via Tutor wrote:
> If you limit your SQL to queries fetching raw fields you
> should find you are working with the portable subset of
> standard SQL most of the
On Wed, Sep 13, 2017 at 2:55 AM, Peter Otten <__pete...@web.de> wrote:
> boB Stepp wrote:
>>
>> And these would be the SQL commands/statements I would have
>> cursor.execute use from the sqlite3 module. They would be different
>> depending on which database product I was using. Am I horribly
>>
On Wed, Sep 13, 2017 at 2:41 AM, Alan Gauld via Tutor wrote:
> The classic approach is to have 3 tiers in the architecture.
> 1) UI layer - usually a GUI toolkit - the VC part of MVC
> 2) Business logic - its the M bit of MVC... and where most OOP happens
> 3) data access - the
2017-09-13 3:58 GMT+02:00 boB Stepp :
> On Tue, Sep 12, 2017 at 2:17 PM, Mats Wichmann wrote:
> > On 09/12/2017 01:05 PM, boB Stepp wrote:
> >> As I continue to read about SQL, one thing jumps out: There are many
> >> differences between how SQL
boB Stepp wrote:
> On Tue, Sep 12, 2017 at 2:17 PM, Mats Wichmann wrote:
>> On 09/12/2017 01:05 PM, boB Stepp wrote:
>>> As I continue to read about SQL, one thing jumps out: There are many
>>> differences between how SQL statements are implemented among the
>>> different
On 12/09/17 20:05, boB Stepp wrote:
As I continue to read about SQL, one thing jumps out: There are many
differences between how SQL statements are implemented
usage of SQL. So how does one write one's python program to be
DB-agnostic? And if this is impossible, then what is the best way
On Tue, Sep 12, 2017 at 8:58 PM, boB Stepp wrote:
> On Tue, Sep 12, 2017 at 2:17 PM, Mats Wichmann wrote:
>> On 09/12/2017 01:05 PM, boB Stepp wrote:
>>> As I continue to read about SQL, one thing jumps out: There are many
>>> differences between how
On Tue, Sep 12, 2017 at 2:17 PM, Mats Wichmann wrote:
> On 09/12/2017 01:05 PM, boB Stepp wrote:
>> As I continue to read about SQL, one thing jumps out: There are many
>> differences between how SQL statements are implemented among the
>> different database products. Even for
From: Tutor <tutor-bounces+sjeik_appie=hotmail@python.org> on behalf of boB
Stepp <robertvst...@gmail.com>
Sent: Tuesday, September 12, 2017 7:05:39 PM
To: tutor
Subject: [Tutor] How to write database-agnostic python code? (Is this even
possible?)
As I continue t
On 09/12/2017 01:05 PM, boB Stepp wrote:
> As I continue to read about SQL, one thing jumps out: There are many
> differences between how SQL statements are implemented among the
> different database products. Even for relatively simple,
> straightforward things like field concatenation. One DB
As I continue to read about SQL, one thing jumps out: There are many
differences between how SQL statements are implemented among the
different database products. Even for relatively simple,
straightforward things like field concatenation. One DB might use
"||" as the operator. Another uses
19 matches
Mail list logo