Slashdot Mirror

> Does Python have something equivalent?

Take a look at SQLAlchemy. You'll cry at how primitive ActiveRecord is by comparison. If you really need to get your ActiveRecord pattern on (it's the name of a pattern, not a product), there's always the much less powerful, but much simpler and still popular SQLObject.

Then there's Django's ORM, GeniuSQL, Storm, Axiom...

For beginners register_globals can create nasty suprises, but for those who know that it is on and write the code accordingly, I don't see what is the problem with register_globals being enabled.

Most PHP programmers ARE beginners, so it creates many many unnecessary nasty surprizes. And for experts, it does not give you anything that you can't already do another way. It adds no real value to the language for experts (of which there are few), and totally screws beginners (of which there are many). Now please explain why you're apologizing for PHP and making excuses for why register_globals is still part of the language after all these years everyone knew it was wrong? I ask again: why did they make such a horrible mistake in the first place?

One of the biggest problems currently with PHP is the lack of good database module with support for multiple different database engines with things like prepared statements.

That's ironic, because people often repeat the myth that PHP makes it easy to interface with the database. Easy but deadly. The reality that PHP has horrible database handling is what's causing PHP programmers to defect to Ruby on Rails (which has ActiveRecord) in droves. Zend tried to imitate ActiveRecord but that resulted in the ZActiveRecord Boondoggle. Python has some excellent database interfaces and object-relation mappers, like SQLObject and SQLAlchemy, which beat the pants of anything PHP has to offer.

-Don

Not only is the PHP development team negligent when it comes to dealing with security bugs, but they're incompetent when it comes to understanding the limitations of their own language, the tenants of object oriented programming, and database object-relational mapper design.

Here is quick summary of my previous post about Zend's ZActiveRecord Boondoggle:

The creators of PHP are morons, and their support company Zend is dishonest and incompetent. The ZActiveRecord boondoggle demonstrates exactly what I mean: They can't program their way out of a paper bag, an don't even understand the limitations of the very language that they haphazardly "designed".

To summarize: [Criticism of PHP "references".] [Criticism of PHP "object system".] [Description of "static methods".] [Description of Ruby on Rail's ActiveRecord.] [Description of "ZActiveRecord", Zend's lame half-baked cargo cult attempt to ape ActiveRecord.] [Zend busted for misleading screencast.] [Blog posting that proves: ZActiveRecord Can't Work.] [Zend misunderstood their own language's object system, showed fake code in a screencast that could not possibly work (because of a PHP bug), and made promises of ZActiveRecord they couldn't keep, because of that stupid bug they refused to fix.] [Longstanding bug that PHP static methods that the developers refuse to fix.] [Summary of comments on the bug that prevents anyone from writing an ActiveRecord-like ORM in PHP.] [Final word from andi, calls it expected behavior, demonstrating how he misunderstands object oriented programming, and casually dismisses all the bug report's valid comments.] [Zend gets hoisted on their own pitard by this very bug.]

And here's the final word from andi: "Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ [php.net] and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php [php.net] This is expected behavior. self:: binds statically to its class (to the best of my knowledge other languages like C++ don't support this either as they require to explicitly use the class name). There are actually advantages also to this approach as they allow you to protect and encapsulate functinality."

Since Zend's dishonest and embarassing public-relations disaster with the ZActiveRecord Boondoggle, Zend has quietly withdrawn their plans for ZActiveRecord, instead of fixing the stupid bug that made it impossible to implement and ORM like ActiveRecord in PHP.

It's not just security that the PHP developers and Zend don't care about. They also don't care about nor understand object oriented programming, nor database object-relational mapping.

There is absolutely no reason to use PHP, when there are great languages like Python with extremely powerful, easy to use, safe and secure, database independent, object-relational mappers like SQLObject , and intelligent scalable SQL toolkits with multiple modular ORMs like SQLAlchemy. That stuff so blows away PHP's horribly insecure string-concatination approach to SQL, and all of the kludgy PHP database libraries people have cobbled together over the years.

-Don

Osty, you have poor reading comprehension. You're attacking exactly the opposite of what I was saying. Go back and read my message you're replying to more carefully, and while you're at it, read the article and watch the video so you'll be more qualified to participate in the discussion.

My point is that SQLObject does insulate you from SQL injection attacks and database dependencies, in ways that Ruby's ActiveRecord does not.

Of course you're ignoring the problem of database portability, because the hammer you want to attack all problems with seems to be stored procedures. If the goals are database portability and database application programming with a scripting language like Python or Ruby, then your hammer breaks the original goals, so it's the wrong hammer. I want to integrate my existing Python code with the database, not rewrite it all as stored procedures -- that would make no sense whatsoever. If I wanted somebody to tell me to write database dependent code, lock myself into the biggest database with the most features, and give up my scripting language of choice, then I'd call Oracle, bend over, and do exactly what they told me. But I'm not that massochistic.

Here is a typical snippet of Ruby/ActiveRecord code, and you can clearly see that it has SQL code written in as quoted strings (sorry about the indentation -- slashdot is now ignoring nbsp's as well as pre's, which makes it hard to discuss code):

def self.authenticate(login, pass)
find_first(["login = ? AND password = ?", login, sha1(pass)])
end

Here is the equivalent Python/SQLObject code, which you can see uses Python syntax to accomplish the same thing, without quoting any SQL code at all:

def authenticate(self, login, pass):
return User.select(AND(User.q.login == login, User.q.password == sha1(pass)))[0]

This is accomplished with the "SQLBuilder" utility, that lets you write python expressions like "AND(person.q.first_name == 'John', person.q.last_name == 'Doe')" instead of raw SQL expressions like "(person.first_name = 'John' AND person.last_name = 'Doe')".

SQLObject also supports methods called "startswith()" and "endswith()" and a function called "LIKE", which insulate you from the differences between SQL "LIKE" syntaxes, so you can portably write "User.q.firstName.startswith('X')" instead of "User.firstName LIKE 'X%'".

Of course the 15 minute Ruby on Rails demo didn't get deep enough into programming a complex web application, that they had to show you any of the SQL dependencies and other warts of Ruby on Rails. They're evangelizing, not airing dirty laundry -- what do you expect?

SQLObject and ActiveRecord are based on a lot of the same ideas (Martin Fowler's Active Record model), but SQLObject is also different than ActiveRecord in many ways. Ben Bangert's compares SQLObject and ActiveRecord in his talk, "Presentation on SQLObject & FormEncode", that he gave at the Bay Area Python users group.

SQLObject is a pure ORM (Object-Relational Mapper), while ActiveRecord is a full fledged Model (as in MVC). Both SQLObject and ActiveRecord let you automatically read in an existing database schema. But SQLObject also lets you define the schema in Python and automatically generates the tables (for any database) from the Python declarations -- it works either way! SQLObject also supports runtime column changes, so it can be used to implement dynamic database schema editors.

-Don

To me it seems like a silly exercise to replicate rails in python or what have you.

1. TurboGears is not a Rails clone.
2. Most parts of TurboGears existed before Rails: CherryPy, SQLObject, FormEncode (and Python of course).
3. Kid is most closely related to Zope Page Templates (from the Python world), not anything from Rails.
4. MochiKit has a certain relationship to Prototype (the Javascript library from Rails), and is compatible with it. However, it's not that the author particularly likes Prototype.

Rails has taught us some important lessons, but they aren't really technical lessons:

1. We shouldn't sit around and say "oh, those poor people using PHP/Java/etc, too bad they don't know about what you can do using X". Instead we should talk more loudly and insistently about the advantages of our platforms. If you do it right people will pay attention.
2. We haven't concentrated enough on full-stack integration. We've been overvaluing decoupled pick-and-choose components. Full-stack integration doesn't have to mean coupling -- it can just be a matter of presentation, and making sure tools are complimentary. Not all of the Python frameworks are coming at it from this direction, but TurboGears very much is.
3. Things like screencasts are nice.

After looking at various pieces of Rails, these lessons have stood out to me, but the particular technology in Rails has not. Sure, there are some good ideas, but nothing radical, and there's good ideas everywhere waiting to be mined. We're not beneath mining other people's ideas, but it does not follow that the result is merely a "replication" in part or in whole.

As for Ruby: I think the two languages are largely equivalent in terms of what you can do. I would not say the same about PHP or Java. As for Rails specifically, I think it is only ahead of Python options in the second derivative. With conscious players the second derivative doesn't mean a whole lot.

It makes it easier for the programmer.

However, I really wrote this to say what it is not an advantage. I have two words for you: Outer Joins.

First of all, an Outer Join (of which LEFT JOIN is the most common) is used to get information from two tables, whether or not the information in one table has matching information in the other table. A real world example would be a list of customers and the number of orders they've placed with your business. With a normal (inner) join, customers who have never placed an order would not be listed.

I keep seeing people mentioned SQLObject, so I'll pull up a selected reference to the SQLObject FAQ: "How can I do a LEFT JOIN?."

The Simple method on that page is what I believe is referred to as the "1+N" problem. 1 Query becomes 1+N queries, where N is the number of results in the first query's result set. Needless to say, this doesn't scale well.

The Efficient method is actually much more complicated than the SQL to do the query, and it still takes 2 queries to boot.

This is why you'll never see a large business relying on an SQL builder to build queries. In the hands of someone who knows what they're doing, hand written queries are optimized much better than generated ones.

It makes it easier for the programmer.

However, I really wrote this to say what it is not an advantage. I have two words for you: Outer Joins.

First of all, an Outer Join (of which LEFT JOIN is the most common) is used to get information from two tables, whether or not the information in one table has matching information in the other table. A real world example would be a list of customers and the number of orders they've placed with your business. With a normal (inner) join, customers who have never placed an order would not be listed.

I keep seeing people mentioned SQLObject, so I'll pull up a selected reference to the SQLObject FAQ: "How can I do a LEFT JOIN?."

The Simple method on that page is what I believe is referred to as the "1+N" problem. 1 Query becomes 1+N queries, where N is the number of results in the first query's result set. Needless to say, this doesn't scale well.

The Efficient method is actually much more complicated than the SQL to do the query, and it still takes 2 queries to boot.

This is why you'll never see a large business relying on an SQL builder to build queries. In the hands of someone who knows what they're doing, hand written queries are optimized much better than generated ones.

As opposed to SQLObject, which was mentioned in the summary. It allows you to make the objects in your program persistent by transparently storing them in a traditional SQL database. All you have to do is inherit from a base class and set/get the object's attributes normally.

def index():
    return 'Some text'
index.exposed=1

def loginUser(Name, Password):
    #... stuff goes here
 
loginUser.exposed=1

dude=Person.get(1) # SELECT * from TABLE where ID=1
 
dude.name='Fred' # UPDATE TABLE SET name='Fred' WHERE ID=1

class Person(SQLObject):
    _fromDatabase=True

I'm also interested in other Python based web frameworks. I've done lots of Zope/Plone programming, and I share your frustration with that "skyscraper stack" of software. I'm curious to know why you think webware and cherrypy suck.

I've been using an ORM (object relational manager) called SQLObject, by Ian Bicking (the author of Webware), and it seems to work pretty well. (It's pretty simple so it doesn't do everything, but it's extensible.)

I'd love to know what you think of PyDO2, the ORM in Skunkweb? How does it compare to Ruby on Rails' ORM, ActiveRecord?

At first glance at the sample code you provided, I noticed that it uses a non-standard variant of XML syntax. That is a big show-stopper problem, which means you can't develop your templates with any off-the-shelf XML editors, and you can't take advantage of any of the standard XML tools to process, generate and validate templates. If you're not going to use standard XML syntax, then why bother making it look anything like XML at all, since you've forsaken the entire universe of XML tools.

If you're going to invent your own markup language, then you'd better have the resources of IBM and 30 years to invest in reinventing the wheel. Otherwise, the benefits of sticking with standard XML syntax far outweigh any upside of bastardizing it with your own special syntax enhancements.

-Don

Then, just to mix things up, you have SAP DB, which is open source with a very proprietary background, much like Firebird. And probably with a lot of the same problems in terms of administration and code accessibility.

I certainly wish the developers no ill will, or to disparage their efforts -- but I've yet to see the argument for using Firebird outside of legacy projects. It's easy to argue MySQL vs. Firebird, but PostgreSQL is the real competitor.