Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: Zope: DB

Re: Zope-DB Digest, Vol 72, Issue 1

 

 

Zope db RSS feed   Index | Next | Previous | View Threaded


richard at scholarpack

Aug 25, 2010, 3:04 AM

Post #1 of 10 (3423 views)
Permalink
Re: Zope-DB Digest, Vol 72, Issue 1

Please can someone explain why ORM is better than speaking directly to
the database? Isn't this just adding another layer of complexity which
in huge databases is certainly not needed.


On 24/08/10 17:00, zope-db-request [at] zope wrote:
> Send Zope-DB mailing list submissions to
> zope-db [at] zope
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://mail.zope.org/mailman/listinfo/zope-db
> or, via email, send a message with subject or body 'help' to
> zope-db-request [at] zope
>
> You can reach the person managing the list at
> zope-db-owner [at] zope
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Zope-DB digest..."
>
>
> Today's Topics:
>
> 1. ZSQL Question - Insert multiple rows in one statement?
> (Mark Phillips)
> 2. Re: ZSQL Question - Insert multiple rows in one statement?
> (Andreas Jung)
> 3. Re: ZSQL Question - Insert multiple rows in one statement?
> (Sascha Gottfried)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Tue, 24 Aug 2010 08:03:21 -0700
> From: Mark Phillips<mark [at] phillipsmarketing>
> Subject: [Zope-DB] ZSQL Question - Insert multiple rows in one
> statement?
> To: zope-db [at] zope
> Message-ID:
> <AANLkTinwD33h-HP1UpzWLyoFL3U12qCFDZ9pJmvdYg_c [at] mail>
> Content-Type: text/plain; charset="iso-8859-1"
>
> When I retrieve multiple values from a selection box, I need to create a
> loop somewhere to insert the multiple values (rows) into a table. Is there a
> way to do this within a ZSQL statement, or is it best to do the looping in a
> Python script?
>
> My specific example....
>
> table 1 (Players) has information about players (i.e. team members for a
> sports team). There is a primary key - playerID
> table 2 (Seasons) has information about each season - primary key is
> seasonID
> table 3 (PlayerSeasons) has two columns - playerID and seasonID.
>
> The form to crud a player has a combobox where one can select multiple
> seasons for a player. When I do an add or update, I have to add one or more
> rows to the PlayerSeasons table. Does this loop have to be in a Python
> script, or can it be implemented in ZSQL? I looked at the 'multiple'
> keyword, but all the examples indicate that it apples to sql tests, such as
> testing against a set of values. I can't seem to find any examples where one
> is inserting multiple rows into a table.
>
> Thanks!
>
> Mark
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: http://mail.zope.org/pipermail/zope-db/attachments/20100824/e5237d80/attachment-0001.html
>
> ------------------------------
>
> Message: 2
> Date: Tue, 24 Aug 2010 17:06:21 +0200
> From: Andreas Jung<lists [at] zopyx>
> Subject: Re: [Zope-DB] ZSQL Question - Insert multiple rows in one
> statement?
> To: Mark Phillips<mark [at] phillipsmarketing>
> Cc: zope-db [at] zope
> Message-ID:<4C73DFED.2000100 [at] zopyx>
> Content-Type: text/plain; charset="iso-8859-1"
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> I would assume that you can use DTML-IN for looping and generating
> multiple SQL statements of the same kind. You have to ensure that
> the statements having a proper delimiter (there was something in DTML?!
> DTML-SQLDELIMITER?...no idea, you need to checks the docs of this
> ancient technology).
>
> - -aj
>
> Mark Phillips wrote:
>
>> When I retrieve multiple values from a selection box, I need to create a
>> loop somewhere to insert the multiple values (rows) into a table. Is
>> there a way to do this within a ZSQL statement, or is it best to do the
>> looping in a Python script?
>>
>> My specific example....
>>
>> table 1 (Players) has information about players (i.e. team members for a
>> sports team). There is a primary key - playerID
>> table 2 (Seasons) has information about each season - primary key is
>> seasonID
>> table 3 (PlayerSeasons) has two columns - playerID and seasonID.
>>
>> The form to crud a player has a combobox where one can select multiple
>> seasons for a player. When I do an add or update, I have to add one or
>> more rows to the PlayerSeasons table. Does this loop have to be in a
>> Python script, or can it be implemented in ZSQL? I looked at the
>> 'multiple' keyword, but all the examples indicate that it apples to sql
>> tests, such as testing against a set of values. I can't seem to find any
>> examples where one is inserting multiple rows into a table.
>>
>> Thanks!
>>
>> Mark
>>
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> Zope-DB mailing list
>> Zope-DB [at] zope
>> https://mail.zope.org/mailman/listinfo/zope-db
>>
>
> - --
> ZOPYX Limited | zopyx group
> Charlottenstr. 37/1 | The full-service network for Zope& Plone
> D-72070 T?bingen | Produce& Publish
> www.zopyx.com | www.produce-and-publish.com
> - ------------------------------------------------------------------------
> E-Publishing, Python, Zope& Plone development, Consulting
>
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (Darwin)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iQGUBAEBAgAGBQJMc9/tAAoJEADcfz7u4AZjlPwLwNiLG+kZUrlZ+BuFEWKL42eE
> bmzllHixdEq6qy2gHP3pbf5AmICS66JJGfqaI6Gv7JqxY6XM1N35oeXK7PzUk+gb
> PYPtIwN62HMQzrvYXB6JHyFEkyMuOd9MFyyHMgh24JqC6xtMBbYI3+yjiXJor1QP
> Xd56qoxWmhHZVnC2YhddpR3DLlAx/qebi2mk+C15g2C+LkVzz0J2rHb5FNB/Izdt
> uJmknn9pDjBewSQhtPIsX/rj7R4SUtJUZ78H8Isn2yoEftsG4ONtpzT3O9ICXF4R
> Y4V/iV9KepUoxU5dpH9YDTl00YA6UVvyafhDufkPzq5dnKUQL+QzPXFcmC9tSRux
> OIDiTOLZwYVS0a5hT/OUtYB1p+JGhITxLKxspXH4vJ5po8IJR7CmxO0FOooqGeOc
> muaWclDrxPIsyWEAEZg6+ahyydWgFCePuMLCrEEvhZRpx4DxvhisXRVB5V/h6Z7L
> OSSYDljCM/mu1mKIPRUuHqBlc0mB4qI=
> =1o0Q
> -----END PGP SIGNATURE-----
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: lists.vcf
> Type: text/x-vcard
> Size: 316 bytes
> Desc: not available
> Url : http://mail.zope.org/pipermail/zope-db/attachments/20100824/7935a0d8/attachment-0001.vcf
>
> ------------------------------
>
> Message: 3
> Date: Tue, 24 Aug 2010 17:55:29 +0200
> From: Sascha Gottfried<s.gottfried [at] srz>
> Subject: Re: [Zope-DB] ZSQL Question - Insert multiple rows in one
> statement?
> To: zope-db [at] zope
> Message-ID:<4C73EB71.8080909 [at] srz>
> Content-Type: text/plain; charset="iso-8859-1"
>
> Hi Mark,
>
> it is best to do the looping in python. consider the python script as
> the proper place to process the form values taken from the request
> variable. No problem to invoke multiple zsql method calls from within
> this script. I even remember that all invoked zsql methods in one
> requests belong to a transaction. If one fails, a rollback is done. Your
> ZSQL connection has to be configured properly to use transactions and
> your server has to support them as well.
>
> Just in case you do not already found this - latest zope book and the
> chapter about SQL connectivity
> http://docs.zope.org/zope2/zope2book/RelationalDatabases.html
>
> Am 24.08.2010 17:03, schrieb Mark Phillips:
>
>> When I retrieve multiple values from a selection box, I need to create
>> a loop somewhere to insert the multiple values (rows) into a table. Is
>> there a way to do this within a ZSQL statement, or is it best to do
>> the looping in a Python script?
>>
>> My specific example....
>>
>> table 1 (Players) has information about players (i.e. team members for
>> a sports team). There is a primary key - playerID
>> table 2 (Seasons) has information about each season - primary key is
>> seasonID
>> table 3 (PlayerSeasons) has two columns - playerID and seasonID.
>>
>> The form to crud a player has a combobox where one can select multiple
>> seasons for a player. When I do an add or update, I have to add one or
>> more rows to the PlayerSeasons table. Does this loop have to be in a
>> Python script, or can it be implemented in ZSQL? I looked at the
>> 'multiple' keyword, but all the examples indicate that it apples to
>> sql tests, such as testing against a set of values. I can't seem to
>> find any examples where one is inserting multiple rows into a table.
>>
>> Thanks!
>>
>> Mark
>>
>>
>> _______________________________________________
>> Zope-DB mailing list
>> Zope-DB [at] zope
>> https://mail.zope.org/mailman/listinfo/zope-db
>>
>>
>>
>> __________ Hinweis von ESET NOD32 Antivirus, Signaturdatenbank-Version 5393 (20100824) __________
>>
>> E-Mail wurde gepr?ft mit ESET NOD32 Antivirus.
>>
>> http://www.eset.com
>>
>>
>>
>
>
>
> __________ Hinweis von ESET NOD32 Antivirus, Signaturdatenbank-Version 5393 (20100824) __________
>
> E-Mail wurde gepr?ft mit ESET NOD32 Antivirus.
>
> http://www.eset.com
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: http://mail.zope.org/pipermail/zope-db/attachments/20100824/5dcd37b0/attachment-0001.html
>
> ------------------------------
>
> _______________________________________________
> Zope-DB mailing list
> Zope-DB [at] zope
> https://mail.zope.org/mailman/listinfo/zope-db
>
>
> End of Zope-DB Digest, Vol 72, Issue 1
> **************************************
>

_______________________________________________
Zope-DB mailing list
Zope-DB [at] zope
https://mail.zope.org/mailman/listinfo/zope-db


lists at zopyx

Aug 25, 2010, 3:09 AM

Post #2 of 10 (3322 views)
Permalink
Re: Zope-DB Digest, Vol 72, Issue 1 [In reply to]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Richard Harley wrote:
> Please can someone explain why ORM is better than speaking directly to
> the database? Isn't this just adding another layer of complexity which
> in huge databases is certainly not needed.

Modifying the database schema (adding a new field) requires usually
changes in tons of SQL methods..updating your ORM schema definition
usually takes only one or a few lines of code.

Or why the hell do you want to write complicated SQL code (I
remember legacy code of a co-worker to tons of complex JOINs)
yourself while you could implement the same functionality in much
nicer way using Python?

If you ask me: writing SQL is for masochists.

- -aj
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQGUBAEBAgAGBQJMdOvsAAoJEADcfz7u4AZjqyALwNWRbc5Pz3keM2x1wkDQfwfU
WdtHLdNvLO6jIRMadMjlO4lOgPU0/ANIlkrUFgmstiEkpEt4zj8IIBWYZfdkrryo
6Cb5OeYN+/stFURDSdqGPViJYxybbPFd2pmcX5HW9W9msxIsZsC7mmjLWgUWQEY4
XXZBLbSTWB3DQt1gOXXNrntPzuSopad6QUb/Pqb/JWF7dtE3WYFY2/ar0YWOd/iU
I7K3rKSTnQaBiDBwFrdrm/hHgeA34zlCs4M0qb8tWKCLsafwYNojAxdF28ScLSBD
pHbxmcQY3aRqkHFPC1DZLqJNmMqbDitIpeUqgx6oLIc73trk2znRmT/HHFP+UhWU
K72Qs6fBfEu1dvJYCA2iKFk2aE83ckqbdQnpwYtL0S3pVY3V5s1Z1ZQ4T1rz4+19
BnuClXsZEWxfn8nn3uNZ0kpv9RI3Tw2qRgd4L5vk1s/mCFCRUi1riCKkEb/U8ygI
kiJw/Zv6hJrgY74ZA67sfaymJ6hrSfE=
=JGcb
-----END PGP SIGNATURE-----
Attachments: lists.vcf (0.31 KB)


richard at scholarpack

Aug 25, 2010, 3:26 AM

Post #3 of 10 (3288 views)
Permalink
Re: Zope-DB Digest, Vol 72, Issue 1 [In reply to]

Hmmm..If the database was modeled properly in the first place if
wouldn't be referenced in many different places therefore it would not
require changes in tons of SQL methods.

SQL code isn't complicated, it does exactly what it says on the tin!
(most of the time :)). ORM encourages lazy programming = problems later
down the line.


On 25/08/10 11:09, Andreas Jung wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Richard Harley wrote:
>
>> Please can someone explain why ORM is better than speaking directly to
>> the database? Isn't this just adding another layer of complexity which
>> in huge databases is certainly not needed.
>>
> Modifying the database schema (adding a new field) requires usually
> changes in tons of SQL methods..updating your ORM schema definition
> usually takes only one or a few lines of code.
>
> Or why the hell do you want to write complicated SQL code (I
> remember legacy code of a co-worker to tons of complex JOINs)
> yourself while you could implement the same functionality in much
> nicer way using Python?
>
> If you ask me: writing SQL is for masochists.
>
> - -aj
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (Darwin)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iQGUBAEBAgAGBQJMdOvsAAoJEADcfz7u4AZjqyALwNWRbc5Pz3keM2x1wkDQfwfU
> WdtHLdNvLO6jIRMadMjlO4lOgPU0/ANIlkrUFgmstiEkpEt4zj8IIBWYZfdkrryo
> 6Cb5OeYN+/stFURDSdqGPViJYxybbPFd2pmcX5HW9W9msxIsZsC7mmjLWgUWQEY4
> XXZBLbSTWB3DQt1gOXXNrntPzuSopad6QUb/Pqb/JWF7dtE3WYFY2/ar0YWOd/iU
> I7K3rKSTnQaBiDBwFrdrm/hHgeA34zlCs4M0qb8tWKCLsafwYNojAxdF28ScLSBD
> pHbxmcQY3aRqkHFPC1DZLqJNmMqbDitIpeUqgx6oLIc73trk2znRmT/HHFP+UhWU
> K72Qs6fBfEu1dvJYCA2iKFk2aE83ckqbdQnpwYtL0S3pVY3V5s1Z1ZQ4T1rz4+19
> BnuClXsZEWxfn8nn3uNZ0kpv9RI3Tw2qRgd4L5vk1s/mCFCRUi1riCKkEb/U8ygI
> kiJw/Zv6hJrgY74ZA67sfaymJ6hrSfE=
> =JGcb
> -----END PGP SIGNATURE-----
>

_______________________________________________
Zope-DB mailing list
Zope-DB [at] zope
https://mail.zope.org/mailman/listinfo/zope-db


lists at zopyx

Aug 25, 2010, 3:43 AM

Post #4 of 10 (3295 views)
Permalink
Re: Zope-DB Digest, Vol 72, Issue 1 [In reply to]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Richard Harley wrote:
> Hmmm..If the database was modeled properly in the first place if
> wouldn't be referenced in many different places therefore it would not
> require changes in tons of SQL methods.

Perhaps you haven't work with large installation using SQL heavily?
After having ported a project with roughly 200 ZSQL methods to
Sqlalchemy: it was a *huge* win working with the backend on the Python
level and dealing with database entities like Python objects.

>
> SQL code isn't complicated, it does exactly what it says on the tin!
> (most of the time :)).

SQL can become *very complicated* - ever tried to understand complex
SQL queries of other people? Working with a proper database model
on the Python level is much easier. Yes, you are moving complexity from
SQL to Python and ORM configuration can be confusing as well. However
a descriptive model of a database in Python with its relations is much
easier to handle than dealing with it on the SQL layer directly.

> ORM encourages lazy programming = problems later
> down the line.

Nonsense - using SQLAlchemy for more than four years now in four or five
larger projects and it is a major win regarding productivity, software
architecture, implementation and testing.

- -aj


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQGUBAEBAgAGBQJMdPPnAAoJEADcfz7u4AZj6dULv13bzwtodOh1mM0hdl/OamKE
zBlXNMbcKWlZ0pFErFGWuhCQDjgFBTI5nXuNE/py8Ckmzdzrss2Opk1fselyv6qT
AC/++/FX/Zv5HA7yzVKeBGJ88KIoc/XcFm/5syQrbik67mSCtJcQyjoIOrjGXIy/
HmlbWzRYOYM7hORTkWEmsjPFEjlNfQFUx01CkAstkOp2nAsQe0LH2X9N2gs6BI1H
IORI0u0GkNPvkwXJTgHEoR62bPmrWS+MANdLORQI62G7Rm1WG8cZ/jMzUH6yT0r6
p0bGnca2eux3JyvBSm4p+8Ap64zEbjxhB/Iww5qzojSY+xgZmG0DUJKUAMeXMYZU
dd5es9CmoDRNsMjDfBsnciSRcHw9S+T/eRdcf8YEiUPkeSC1P/4RIbgk7vIWnyef
KtlNYoHCVL8IUIYAGOJNytiTp1Oxg9Q581KM2auFZpUSlZBLafovqGvJSCudxYbs
SlSiXx7aI6uv5vPLuOjMF/ZXPvfKp6E=
=Lrga
-----END PGP SIGNATURE-----
Attachments: lists.vcf (0.31 KB)


charlie at egenix

Aug 25, 2010, 5:59 AM

Post #5 of 10 (3340 views)
Permalink
Re: "My ORM is better than yours!" [In reply to]

Hi,

I think the discussion is always useful but prefer it to be less polemic.

Am 25.08.10 12:43, schrieb Andreas Jung:

> SQL can become *very complicated* - ever tried to understand complex
> SQL queries of other people? Working with a proper database model
> on the Python level is much easier.

When mapping classes to relations, sure. OTOH. I have no problem
understanding properly modelled relational schema. As Chris Date points
out "a relation is an object".

I'm not a big fan of SQL per se - I think it manages to make a travesty
of the declarative approach and makes some things which should be easy
tricky. Things are improving with things like windowing functions.

> Yes, you are moving complexity from
> SQL to Python and ORM configuration can be confusing as well. However
> a descriptive model of a database in Python with its relations is much
> easier to handle than dealing with it on the SQL layer directly.

Depending on how the "mapping" (it's actually the generation of SQL on
the fly) happens this can lead to extremely weird modelling. The SA
modelling of subclasses is weird, incorrect in my view. At Europython
Hannu Krosing showed some stats of direct access over the active record
approach. From what I recall of Trac and Django the iterating over large
sets can indeed present a bottleneck which only a good SQL query can remove.

>> > ORM encourages lazy programming = problems later
>> > down the line.

> Nonsense - using SQLAlchemy for more than four years now in four or five
> larger projects and it is a major win regarding productivity, software
> architecture, implementation and testing.

I think SA has the advantage over some approaches in that it lets you do
all the schema in the database, gives you some control over whether
queries should be lazy or not, etc. and letting you write handcrafted
SQL when necessary (it's a great convenience not to have to write them
for getters and setters).

Nevertheless, any programmer working with a relational database should
have a good understanding of the relational model and the core SQL
constructs.

Furthermore, in my view any good Python programmer should be prepared to
look at other approaches; indeed, I think this is a core advantage of
Python. The Muldis-D project (which is based on the Tutorial D pseudo
language) and Hannu's proposed DORA both offer significant advantages
over SQL and, therefore, SQL generation.

Charlie
--
Charlie Clark
eGenix.com

Professional Python Services directly from the Source
>>> >>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
_______________________________________________
Zope-DB mailing list
Zope-DB [at] zope
https://mail.zope.org/mailman/listinfo/zope-db


mal at egenix

Aug 26, 2010, 5:41 AM

Post #6 of 10 (3294 views)
Permalink
Re: ORMs (Zope-DB Digest, Vol 72, Issue 1) [In reply to]

Richard Harley wrote:
> Please can someone explain why ORM is better than speaking directly to
> the database? Isn't this just adding another layer of complexity which
> in huge databases is certainly not needed.

It really all depends on what your needs are. This is my
experience:

If you just need to work with a simple database schema, change
schemas frequently, have straight-forward queries and don't
like or know SQL, you're probably better off with an ORM hiding SQL
away from you.

If you're working with more complex schemas and queries, need to
care about execution performance, want to use advanced database
techniques and can manage SQL (which really isn't all that difficult),
then you're better off writing straight SQL.

As for managing SQL statements and queries, this is usually best
done using an application specific thin abstraction layer. That
way you keep the queries in one place and can easily make
changes, if required.

Whether ZSQLMethods are a good way of implementing such a layer
is questionable - having those methods in the ZODB makes changes
difficult to implement. OTOH, they are well integrated into
Zope's object database and very easy to setup and use.

I'd suggest to use a Python class as abstraction layer and have
that use a Zope database connection object(s) for executing and
running the queries within a standard Zope transaction.

This approach then also lets you benefit from the better performance
and more security you get from using standard DB-API binding
parameters. ZSQLMethods only support inlining parameters into
the SQL statements which can result in SQL injection problems
as well as slower performance due to the fact that you're making
it harder for the database to cache access plans.

--
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source (#1, Aug 26 2010)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________

::: Try our new mxODBC.Connect Python Database Interface for free ! ::::


eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
Registered at Amtsgericht Duesseldorf: HRB 46611
http://www.egenix.com/company/contact/
_______________________________________________
Zope-DB mailing list
Zope-DB [at] zope
https://mail.zope.org/mailman/listinfo/zope-db


chris at simplistix

Aug 26, 2010, 5:58 AM

Post #7 of 10 (3296 views)
Permalink
Re: SQLAlchemy [In reply to]

M.-A. Lemburg wrote:
> I'd suggest to use a Python class as abstraction layer

Sounds like an ORM to me ;-)

Seriously, SQLAlchemy lets you do all of the things you're worried
about, performance and flexibility wise, as well as map your sql onto
objects (or not, if you don't actually want objects!) with ease...

Hmm, I guess what I'm actually saying is that ORM or not is one choice,
either way, I'd *strongly* recommend using SQLAlchemy rather than trying
to roll your own abstraction layer of any sort.

cheers,

Chris

_______________________________________________
Zope-DB mailing list
Zope-DB [at] zope
https://mail.zope.org/mailman/listinfo/zope-db


mal at egenix

Aug 26, 2010, 6:25 AM

Post #8 of 10 (3296 views)
Permalink
Re: SQLAlchemy [In reply to]

Chris Withers wrote:
> M.-A. Lemburg wrote:
>> I'd suggest to use a Python class as abstraction layer
>
> Sounds like an ORM to me ;-)

No, there's no "object-relational mapping" being done, only
interfacing between the data used by the application and the
schema you have in the database.

As nice side-effect, you can also add business logic to the
abstraction layer, optimize queries to partly run in Python
and in SQL, reorder your SQL to tweak the database optimizer into
writing good access plans, etc.

> Seriously, SQLAlchemy lets you do all of the things you're worried
> about, performance and flexibility wise, as well as map your sql onto
> objects (or not, if you don't actually want objects!) with ease...
>
> Hmm, I guess what I'm actually saying is that ORM or not is one choice,
> either way, I'd *strongly* recommend using SQLAlchemy rather than trying
> to roll your own abstraction layer of any sort.

If you want yet another abstraction layer between your code
and the database, that's the way to go, yes :-)

SA does provides a general abstraction layer, not the application
specific one I was talking about.

--
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source (#1, Aug 26 2010)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________

::: Try our new mxODBC.Connect Python Database Interface for free ! ::::


eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
Registered at Amtsgericht Duesseldorf: HRB 46611
http://www.egenix.com/company/contact/
_______________________________________________
Zope-DB mailing list
Zope-DB [at] zope
https://mail.zope.org/mailman/listinfo/zope-db


chris at simplistix

Aug 30, 2010, 10:34 AM

Post #9 of 10 (3276 views)
Permalink
Re: SQLAlchemy [In reply to]

M.-A. Lemburg wrote:
> If you want yet another abstraction layer between your code
> and the database, that's the way to go, yes :-)
>
> SA does provides a general abstraction layer, not the application
> specific one I was talking about.

To be honest, I'd prefer to use a powerful, lean, well tested
abstraction layer that's tested by a lot more people than just me rather
than hacking up a specific abstraction layer on each and every project ;-)

Chris

--
Simplistix - Content Management, Batch Processing & Python Consulting
- http://www.simplistix.co.uk
_______________________________________________
Zope-DB mailing list
Zope-DB [at] zope
https://mail.zope.org/mailman/listinfo/zope-db


mal at egenix

Aug 30, 2010, 11:34 AM

Post #10 of 10 (3322 views)
Permalink
Re: SQLAlchemy [In reply to]

Chris Withers wrote:
> M.-A. Lemburg wrote:
>> If you want yet another abstraction layer between your code
>> and the database, that's the way to go, yes :-)
>>
>> SA does provides a general abstraction layer, not the application
>> specific one I was talking about.
>
> To be honest, I'd prefer to use a powerful, lean, well tested
> abstraction layer that's tested by a lot more people than just me rather
> than hacking up a specific abstraction layer on each and every project ;-)

That's not what I'm talking about. Each application has its own
database requirements and it's common practice to centralize this
functionality into an application specific database abstraction layer.

You can, of course, have this layer use SA to add another layer
of abstraction between the application database layer and the database,
if you feel uncomfortable with SQL, or want to abstract the queries
from their database specific SQL implementation, e.g. in order to
support more than one database backend.

--
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source (#1, Aug 27 2010)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
2010-08-19: Released mxODBC 3.1.0 http://python.egenix.com/
2010-09-15: DZUG Tagung, Dresden, Germany 18 days to go

::: Try our new mxODBC.Connect Python Database Interface for free ! ::::


eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
Registered at Amtsgericht Duesseldorf: HRB 46611
http://www.egenix.com/company/contact/
_______________________________________________
Zope-DB mailing list
Zope-DB [at] zope
https://mail.zope.org/mailman/listinfo/zope-db

Zope db RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.