Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Lessons learned defying Joel Spolsky with Django

speakerdeck.com

Post reply on HN
Print view View original

51–60 of 155 posts

Re: Lessons learned defying Joel Spolsky with Django

#51

Post by nemoniac »

drdaeman wrote: post #27
Aqueous wrote: post #15

Earlier quoted context omitted.

Why not just write the SQL?

The only problem I see, is we can't rewrite SQL. I.e., in pseudocode: query = SQL("SELECT * FROM entities WHERE owner = ?", owner=me) ... if some_condition: query = query + SQL.WHERE("OR public = TRUE") ... if other_condition: query = query + SQL("LEFT JOIN things AS t" " ON t.entity_id = entities.id") \ + SQL.WHERE("things.value > 0") ... my_nice_list_of_results = run(query + SQL("LIMIT ?", count)) This should be te…

CLSQL has a functional interface which can do this (http://clsql.b9.com/manual/).

Re: Lessons learned defying Joel Spolsky with Django

#52

Post by lucian1900 »

drdaeman wrote: post #27
Aqueous wrote: post #15

Earlier quoted context omitted.

Why not just write the SQL?

The only problem I see, is we can't rewrite SQL. I.e., in pseudocode: query = SQL("SELECT * FROM entities WHERE owner = ?", owner=me) ... if some_condition: query = query + SQL.WHERE("OR public = TRUE") ... if other_condition: query = query + SQL("LEFT JOIN things AS t" " ON t.entity_id = entities.id") \ + SQL.WHERE("things.value > 0") ... my_nice_list_of_results = run(query + SQL("LIMIT ?", count)) This should be te…

SQLAlchemy lets you do precisely that. Give it a try, I haven't written a line of SQL since I've been using it.

Re: Lessons learned defying Joel Spolsky with Django

#53

Post by zerr »

widdershins wrote: post #46
LockeWatts wrote: post #42

Earlier quoted context omitted.

I'm not really sure why Steve Jobs is your model for code design.

Because he oversaw the creation of 3 of the most successful operating systems of all time? I know he didn't design them, but he was involved in managing the projects. Just playing devil's advocate.

Well, it doesn't mean he evaluated at the code level and decided that rewriting is better than refactoring...

Re: Lessons learned defying Joel Spolsky with Django

#55

Post by zzzeek »

memset wrote: post #31
drdaeman wrote: post #27

Earlier quoted context omitted.

The only problem I see, is we can't rewrite SQL. I.e., in pseudocode: query = SQL("SELECT * FROM entities WHERE owner = ?", owner=me) ... if some_condition: query = query + SQL.WHERE("OR public = TRUE") ... if other_condition: query = query + SQL("LEFT JOIN things AS t" " ON t.entity_id = entities.id") \ + SQL.WHERE("things.value > 0") ... my_nice_list_of_results = run(query + SQL("LIMIT ?", count)) This should be te…

I have always wondered why people have an aversion to stored procedures. They are a programming language in themselves, so you could pass all of your parameters (owner, some_condition, other_condition) into a proc and, depending the logic, return a different cursor to a different query.

it's because the stored procedure development model lacks the tools in order to make integrating with an application-level domain model simple. You end up needing to write not just one persistence layer, that of marshaling your object model to and from SQL statements, but two - all the SQL statements behind your stored procedure layer, and a second to move all the data between the SPs and your object model. To make matters worse, the stored procedures must be written completely by hand without the benefit of any in-application schemas to help compose statements.

One reason for the variety of opinion on this is that different developers make more or less use of domain models in the first place. Those who are accustomed to writing all SQL completely by hand with no helpers at all, and not working with a domain model tend to view the stored procedure approach as equivalent. Those who are accustomed to having at least some simple marshaling layers like a construct that generates an INSERT statement given a list of column names see the SP approach as more tedious since simple techniques like that are usually not easily available, at least in more old school SP languages like TRANSACT-SQL and PL/SQL.

All of that said, I do think this is a problem that can possibly be solved. Postgresql allows SPs to be written in many languages, including Python. I have an ongoing curiousity about the potential to integrate a Python-based object relational system into a stored procedure system. But it might end up looking like EJBs.

Re: Lessons learned defying Joel Spolsky with Django

#56

Post by hcarvalhoalves »

memset wrote: post #31
drdaeman wrote: post #27

Earlier quoted context omitted.

The only problem I see, is we can't rewrite SQL. I.e., in pseudocode: query = SQL("SELECT * FROM entities WHERE owner = ?", owner=me) ... if some_condition: query = query + SQL.WHERE("OR public = TRUE") ... if other_condition: query = query + SQL("LEFT JOIN things AS t" " ON t.entity_id = entities.id") \ + SQL.WHERE("things.value > 0") ... my_nice_list_of_results = run(query + SQL("LIMIT ?", count)) This should be te…

I have always wondered why people have an aversion to stored procedures. They are a programming language in themselves, so you could pass all of your parameters (owner, some_condition, other_condition) into a proc and, depending the logic, return a different cursor to a different query.

The problem with stored procedures is managing it. You have to maintain another, separate codebase. You need to make sure those procedures are "installed" and up to date. Plus, DBMSs don't have a concept of "versions", and those procedures are treated as data. In short, it's hell.

That's one of the pain points RethinkDB is trying to solve, since you write your queries in whatever application language you use and it's parsed and executed in the cluster.

Re: Lessons learned defying Joel Spolsky with Django

#57

Post by nickbruun »

Uchikoma wrote: post #48

Iconfinder. They are profitable? They have business requirements? Joel wrote about the problems of a rewrite when you need to earn money, implement money making features, heavy competition while at the same time maintaining two plattform where one is a moving target. I don't think Iconfinder fits in any of these constraints.

Incorrect. We fit in all of those constraints at the point where a rewrite was decided ;)

Re: Lessons learned defying Joel Spolsky with Django

#58

Post by lucian1900 »

InclinedPlane wrote: post #5
zzzeek wrote: post #4

Don't use just one ORM and then declare "ORM's are stupid". The "object = None" / "object_id = None" issue illustrated here is certainly not a mistake every ORM makes.

Do you have an example of an ORM which is not in some fundamental way "stupid"? I haven't found one yet, but I'd love to know one existed somewhere.

SQLAlchemy has several explicit layers of abstraction, the first of which is an AST for all of SQL. The ORM is entirely optional.

Re: Lessons learned defying Joel Spolsky with Django

#59

Post by ikawe »

zzzeek wrote: post #37
k4st wrote: post #29

Earlier quoted context omitted.

The SQL generated appears correct, unless the underlying database can guarantee that all foreign key constraints are met. That is, I consider this a failure of the user of the ORM to appreciate that the two invocations of filter are not identical. In the former case, the query is verifying that the object_id field cannot be used to find a foreign object--regardless of the value of object_id. This is exactly what it i…

"other_id" and "other" here refer to two different ways of referring to a many-to-one reference between "somemodel" and "othermodel". Asking for rows of "somemodel" where "object_id" is None is the exact same thing as asking for rows from "somemodel" where its reference to "object" is None. Both should produce the same query, the simple one without the JOIN. The query with the JOIN is completely wasteful and not at a…

You're right in that they are largely the same action, but consider this case:

An Owner is deleted without setting the pets.owner_id to NULL. So now there's a row in Pets with an owner_id referring to an Owner that doesn't exist.

These two queries will (rightfully) return different things in this case.

One will return The Pets who have null for an owner_id. The other will return the Pets whose owner_id is NULL AND those who do have an owner_id, but it doesn't reference an existing row in Owner.

Re: Lessons learned defying Joel Spolsky with Django

#60

Post by lmm »

Aqueous wrote: post #15
zzzeek wrote: post #4

Don't use just one ORM and then declare "ORM's are stupid". The "object = None" / "object_id = None" issue illustrated here is certainly not a mistake every ORM makes.

Why not just write the SQL?

Poor tool integration, nonexistent library ecosystem, and the advantages of a single-language codebase.
Post reply on HN