Introducing PloneLounge - a user group for Zope and Plone enthusiasts

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Introducing PloneLounge - a user group for Zope and Plone enthusiasts

gautham hegde
Hello Everyone,

Since this list is about supporting all things python, I wanted to announce to you all the creation of PloneLounge.  A user group for Zope and Plone enthusiasts. 

What is zope?
Zope is an open source application server for building content management systems, intranets, portals, and custom applications. The Zope community consists of hundreds of companies and thousands of developers all over the world, working on building the platform and Zope applications. Zope is written in Python, a highly-productive, object-oriented scripting language.
What is Plone?
Plone
is the leading open source content management system. It's powerful, extensible, and easy-to-use, right out of the box. It runs on an industrial strength application server, and works equally well on Linux, Windows, or OSX.

URL
http://plonelounge.org/

when
Wednesday Feburary 15th between 7:00-9:00 PM

where
CIGNEX Technologies, Inc.
2055 Laurelwood Road, Suite 110
Santa Clara, CA 95054

So if youd like to know a little more about python web frameworks, meet some of the core developers and board members, and discuss your valentines day horror stories, come on over to the meeting.

Cheers,
Gautham

P.S -
It would be great if you could let me know if youre interested in coming by sending me a quick email.

_______________________________________________
Baypiggies mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/baypiggies
Reply | Threaded
Open this post in threaded view
|

Python ORM?

hsuclarklarry
So what is the Python version of Hibernate? Or is this the wrong
question? Do serious Python users believe in relational databases? If
not what is the preferred persistence solution for a midsize data model
-- the kind of thing that would use a hundred tables or so in an old
fashioned client-server database application with a normalized
relational database.


_______________________________________________
Baypiggies mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/baypiggies
Reply | Threaded
Open this post in threaded view
|

Re: Python ORM?

DaveG-4
On Thu, Feb 16, 2006 at 11:32:44PM -0800, Laurence Clark wrote:
> So what is the Python version of Hibernate? Or is this the wrong
> question? Do serious Python users believe in relational databases? If
> not what is the preferred persistence solution for a midsize data model
> -- the kind of thing that would use a hundred tables or so in an old
> fashioned client-server database application with a normalized
> relational database.

As a sometime dba and sometime python purist, I tend to dislike ORMs. They
either run out of power or lead to patterns that fail to take advantage of
what relational databases are good at, or become so complex that it is
difficult to predict what they will do. Notice that all of them let you
escape to writing your own SQL, a hint if ever there was one.

Usually people seek more transparency and simplicity in code, but when
it comes to ORMs some want a whole complicated layer of obsfucatory
library filled with hidden metadata and covert code generators. It is
almost as if SQL was all icky somehow, something to be ashamed of,
covered up and hidden.

Ok, the truth is, SQL is all icky. And historically relational databases were
stuffed down our gullets by the likes of IBM and Oracle. Still the failure of
ANY of the proposed alternatives over the last quarter century must signify
something. Probably that everything else is either ickier or simply
insufficient, or even that SQL systems are the best tool we have for certain
problems.

SQL is about sets. To use it effectively you want to express as much of
your processing as possible in terms of sets and operations on sets.
Instead of writing python to do something to one object, write SQL to do it
to all of the objects at once. The more work you can force the SQL engine to
do in batches and the less interaction with it you have, the better. To do
this effectively, I think you need to understand SQL and have good control
of the queries you write.

One specific problem with ORMs is that they encourage "one at a time"
thinking:

    I have a customer Object, I'll just instantiate it here with a call
    to the ORM ... now I'll have a loop to call the ORM to instantiate all
    the Order objects...

Which is just a relational join that ends up hand coded in python ignoring
25 years of industrial R & D on how to process joins efficiently.

Think of Python as a car or truck and SQL as a freight train. The train only
goes certain places and its all rusty and ugly, but if you have ten million
tons of coal to move across the country it beats a million separate truck
trips. And (to be completely unfair to ORMs) it really really beats dividing
the coal up onto a million trains painted up to look like a truck.

SQL is your friend, don't hide from it, learn to love it.

-dg


--
David Gould                      [hidden email]
If simplicity worked, the world would be overrun with insects.
_______________________________________________
Baypiggies mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/baypiggies
Reply | Threaded
Open this post in threaded view
|

Re: Python ORM?

Ben Bangert
In reply to this post by hsuclarklarry
On Feb 16, 2006, at 11:32 PM, Laurence Clark wrote:

> So what is the Python version of Hibernate? Or is this the wrong
> question? Do serious Python users believe in relational databases? If
> not what is the preferred persistence solution for a midsize data  
> model
> -- the kind of thing that would use a hundred tables or so in an old
> fashioned client-server database application with a normalized
> relational database.

The closest thing to Hibernate in the Python world would most likely  
be SQLAlchemy (http://sqlalchemy.org/), which implements a lot of the  
same enterprise patterns as Hibernate. It lets you stay close to the  
SQL, or abstract away from it as you choose.

- Ben
_______________________________________________
Baypiggies mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/baypiggies
Reply | Threaded
Open this post in threaded view
|

Re: Python ORM?

Shannon -jj Behrens
In reply to this post by DaveG-4
I think RDBMSs are the best thing to happen to business software in
the last 30 years.  I *love* SQL.  However, with all due respect for
David, it does seem that the active record pattern used by Ruby on
Rails, Django, SQLAlchemy (I believe), SQLObject, etc. is actually
helpful.  I liked having the OR Mapper that Django provides, and it
*is* intelligent about generating good SQL and not pulling down
everything into the client.  I think the fact that it lets you drop
down to SQL if you need to is like having your cake and getting to eat
it too.  I've read a lot that says SQLAlchemy is the way to go.

Best Regards,
-jj

On 2/17/06, daveg <[hidden email]> wrote:

> On Thu, Feb 16, 2006 at 11:32:44PM -0800, Laurence Clark wrote:
> > So what is the Python version of Hibernate? Or is this the wrong
> > question? Do serious Python users believe in relational databases? If
> > not what is the preferred persistence solution for a midsize data model
> > -- the kind of thing that would use a hundred tables or so in an old
> > fashioned client-server database application with a normalized
> > relational database.
>
> As a sometime dba and sometime python purist, I tend to dislike ORMs. They
> either run out of power or lead to patterns that fail to take advantage of
> what relational databases are good at, or become so complex that it is
> difficult to predict what they will do. Notice that all of them let you
> escape to writing your own SQL, a hint if ever there was one.
>
> Usually people seek more transparency and simplicity in code, but when
> it comes to ORMs some want a whole complicated layer of obsfucatory
> library filled with hidden metadata and covert code generators. It is
> almost as if SQL was all icky somehow, something to be ashamed of,
> covered up and hidden.
>
> Ok, the truth is, SQL is all icky. And historically relational databases were
> stuffed down our gullets by the likes of IBM and Oracle. Still the failure of
> ANY of the proposed alternatives over the last quarter century must signify
> something. Probably that everything else is either ickier or simply
> insufficient, or even that SQL systems are the best tool we have for certain
> problems.
>
> SQL is about sets. To use it effectively you want to express as much of
> your processing as possible in terms of sets and operations on sets.
> Instead of writing python to do something to one object, write SQL to do it
> to all of the objects at once. The more work you can force the SQL engine to
> do in batches and the less interaction with it you have, the better. To do
> this effectively, I think you need to understand SQL and have good control
> of the queries you write.
>
> One specific problem with ORMs is that they encourage "one at a time"
> thinking:
>
>     I have a customer Object, I'll just instantiate it here with a call
>     to the ORM ... now I'll have a loop to call the ORM to instantiate all
>     the Order objects...
>
> Which is just a relational join that ends up hand coded in python ignoring
> 25 years of industrial R & D on how to process joins efficiently.
>
> Think of Python as a car or truck and SQL as a freight train. The train only
> goes certain places and its all rusty and ugly, but if you have ten million
> tons of coal to move across the country it beats a million separate truck
> trips. And (to be completely unfair to ORMs) it really really beats dividing
> the coal up onto a million trains painted up to look like a truck.
>
> SQL is your friend, don't hide from it, learn to love it.
>
> -dg
>
>
> --
> David Gould                      [hidden email]
> If simplicity worked, the world would be overrun with insects.
> _______________________________________________
> Baypiggies mailing list
> [hidden email]
> http://mail.python.org/mailman/listinfo/baypiggies
>
_______________________________________________
Baypiggies mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/baypiggies
Reply | Threaded
Open this post in threaded view
|

Re: Python ORM?

Keith Dart-2
Shannon -jj Behrens wrote the following on 2006-02-17 at 15:46 PST:
===
> I think RDBMSs are the best thing to happen to business software in
> the last 30 years.  I *love* SQL.  However, with all due respect for
> David, it does seem that the active record pattern used by Ruby on
> Rails, Django, SQLAlchemy (I believe), SQLObject, etc. is actually
> helpful.  I liked having the OR Mapper that Django provides, and it
> *is* intelligent about generating good SQL and not pulling down
> everything into the client.  I think the fact that it lets you drop
> down to SQL if you need to is like having your cake and getting to eat
> it too.  I've read a lot that says SQLAlchemy is the way to go.

===

I have used SQLObjects, and I liked it. However, the syntax was a
little weird. But it does make interfacing to the SQL (mySQL) easier
for the SQL non-expert.

As for other object storages, I also use the Durus persistence package.
My software's whole configuration database is based on it. It makes a
great free-form data storage. My wrapper objects make it look like a
hierarchical file system, except that it stores Python objects.





--

-- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
   Keith Dart <[hidden email]>
   public key: ID: 19017044
   <http://www.dartworks.biz/>
   =====================================================================

_______________________________________________
Baypiggies mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/baypiggies

signature.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Python ORM?

Aahz
In reply to this post by DaveG-4
On Fri, Feb 17, 2006, daveg wrote:
>
> Ok, the truth is, SQL is all icky. And historically relational
> databases were stuffed down our gullets by the likes of IBM and
> Oracle. Still the failure of ANY of the proposed alternatives over the
> last quarter century must signify something. Probably that everything
> else is either ickier or simply insufficient, or even that SQL systems
> are the best tool we have for certain problems.

Note that "relational database" and SQL are not synonymous:

http://www.oreillynet.com/lpt/a/6060
--
Aahz ([hidden email])           <*>         http://www.pythoncraft.com/

"19. A language that doesn't affect the way you think about programming,
is not worth knowing."  --Alan Perlis
_______________________________________________
Baypiggies mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/baypiggies