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

141–150 of 155 posts

Re: Lessons learned defying Joel Spolsky with Django

#141

Post by neilk »

PommeDeTerre wrote: post #128
neilk wrote: post #89

Earlier quoted context omitted.

There are libraries which build up a model of a query - selections, constraints, etc, and only turn it into a string at the point of executing it. SQLAlchemy was already mentioned. In the JavaScript world, there's node-sql. https://github.com/brianc/node-sql

That kind of code often ends up being worse to deal with than the SQL it is replacing. I've always found it kind of odd how there are some people who despise SQL merely for its syntax, yet they'll turn around and advocate the use of libraries which mimic a SQL-like syntax in some other programming language (but do an absolutely terrible job at it). The node-sql examples are atrocious, for example. It's even more obvi…

The complaint was not about SQL's syntax, but that SQL statements as strings are inflexible.

One often wants to have several variants of a SQL statement, beyond simple placeholders for arguments. I've seen several projects that grow a lame templating syntax on top of their SQL strings, to the point that the SQL then becomes incomprehensible.

If this really bugs you, perhaps the ultimate solution would be to actually parse SQL.

   query = sqlParse("SELECT foo FROM bar WHERE quux = 1")
   query2 = query.clone().constraint("quux = 2")

Re: Lessons learned defying Joel Spolsky with Django

#142

Post by JshWright »

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.

I haven't checked this one either way, but I'm curious what SQL would be if they used the 'right' ORM incantation.

filter(object__isnull=True)

https://docs.djangoproject.com/en/dev/ref/models/querysets/#...

Re: Lessons learned defying Joel Spolsky with Django

#143

Post by white_devil »

zzzeek wrote: post #116
white_devil wrote: post #86

Earlier quoted context omitted.

The problem with ORMs seems to be that they're a leaky abstraction. I've been very happy using SQLAlchemy for quite a while now, but I'm intentionally only using the SQL Expression API. Based on my experience with Hibernate, there's always something you want to accomplish that necessitates circumventing your ORM. Not only that, but typically you end up balancing between stuff being unavailable because of lazy-loading…

> The problem with ORMs seems to be that they're a leaky abstraction. I disagree it's a problem. going back to Joel again (!) : "All non-trivial abstractions, to some degree, are leaky." I talk about this a lot in this particular talk: https://www.youtube.com/watch?v=E09qigk_hnY Hibernate was a great influence on me but I like to think that it only introduced some ideas in rough form that we've all had many years to…

Look, I'm willing to believe that SQLAlchemy is the bad-assest ORM on the planet, but I'm not convinced I'll never need to circumvent it to get something done, and I'm free to consider that a problem (along with other commenters, it seems).

As I mentioned, I'm very happy using SQLAlchemy's lower level API. It's a helpful and elegant abstraction over queries and table definitions etc, and I've never needed to circumvent it yet. I'm also convinced that the delightfully flexible/powerful Mako is hands down the best templating library for Python. You, sir, Rock. But you come off as needlessly argumentative in this thread.

Re: Lessons learned defying Joel Spolsky with Django

#144

Post by macspoofing »

akmiller wrote: post #133
macspoofing wrote: post #77

Earlier quoted context omitted.

I disagree. There's a lot of boilerplate ontop of raw SQL that can and should be abstracted away. At some point you'll have to parse out result and build an object graph anyway, it would be nice if it was done for you already. You can also plug-in things like a caching engine easily and transparently. Most ORM systems will give you options. My experience was with Hibernate, which had let you do Object queries, Criter…

"At some point you'll have to parse out result and build an object graph anyway" This type of thinking has to stop! Sure, some times it may be necessary to extract data from SQL and turn it into some type of object. However, most of the time it's enough just to get the data and work with the data directly.

Be serious. I made this argument in another thread: I don't believe for a second that it's good practice to just work with SQL directly in your business logic. You don't want to litter your code with serialization logic. You don't want litter your code with constraint checking everytime you make a query. Even if you don't use an official ORM framework, you will write an abstraction layer that will duplicate some of the ORM functionality.

I worked with redis extensively, and i got to the point where it was too dangerous to simply assume that none of the other guys on the team (or me) wouldn't put some garbage data in a field because from redis' perspective, every key looks the same and every value is as good as the next. We rolled our own abstraction layer, in which keys and values were wrapped in domain specific objects.

Programming languages, and databases are too general to be useful. If you don't 'constrain' them to your domain, you're going to get destroyed once your product or team scales to a certain size.

Re: Lessons learned defying Joel Spolsky with Django

#145

Post by akmiller »

macspoofing wrote: post #144
akmiller wrote: post #133

Earlier quoted context omitted.

"At some point you'll have to parse out result and build an object graph anyway" This type of thinking has to stop! Sure, some times it may be necessary to extract data from SQL and turn it into some type of object. However, most of the time it's enough just to get the data and work with the data directly.

Be serious. I made this argument in another thread: I don't believe for a second that it's good practice to just work with SQL directly in your business logic. You don't want to litter your code with serialization logic. You don't want litter your code with constraint checking everytime you make a query. Even if you don't use an official ORM framework, you will write an abstraction layer that will duplicate some of t…

Not converting data into object graphs does not necessitate working with SQL in your domain model. I'm currently working on an application right now which favors simple data structures (hashes, arrays) over custom entities. It favors a business layer that operates on those data structures over composing dozens of "Model" based classes. That does not mean that persistence logic is littered within my domain.

Re: Lessons learned defying Joel Spolsky with Django

#146

Post by akmiller »

rmrfrmrf wrote: post #134
akmiller wrote: post #133

Earlier quoted context omitted.

"At some point you'll have to parse out result and build an object graph anyway" This type of thinking has to stop! Sure, some times it may be necessary to extract data from SQL and turn it into some type of object. However, most of the time it's enough just to get the data and work with the data directly.

* grabs OO sword and shield and prepares for battle * .

Ha! I have no problem with OO based programming. I do have a problem with OO based solutions for every problem. Sometimes it's worth pursuing alternative solutions, whether procedural or functional or a combination of what makes sense.

Not too mention, what many believe as an OO solution is often times far removed from anything remotely OO.

Re: Lessons learned defying Joel Spolsky with Django

#147

Post by gngeal »

drdaeman wrote: post #139
gngeal wrote: post #111

Earlier quoted context omitted.

"The only problem I see, is we can't rewrite SQL." I believe that the phrase you're looking for is "lack of compositionality".

I fail to see why one can't manipulate parsed SQL's AST. SQLAlchemy shows thas manipulating SQL-inspired objects is perfectly possible. It's only bridge between sqlparse and SQLAlchemy that's missing. I guess, just because nobody had a wish, will and time to finish and share one.

I fail to see why one can't manipulate parsed SQL's AST.

I think that this is the "every problem in CS can be solved by another layer of indirection" part. You're basically sidestepping the issue of SQL not providing the functionality in the first place.

Re: Lessons learned defying Joel Spolsky with Django

#148

Post by zzzeek »

white_devil wrote: post #143
zzzeek wrote: post #116

Earlier quoted context omitted.

> The problem with ORMs seems to be that they're a leaky abstraction. I disagree it's a problem. going back to Joel again (!) : "All non-trivial abstractions, to some degree, are leaky." I talk about this a lot in this particular talk: https://www.youtube.com/watch?v=E09qigk_hnY Hibernate was a great influence on me but I like to think that it only introduced some ideas in rough form that we've all had many years to…

Look, I'm willing to believe that SQLAlchemy is the bad-assest ORM on the planet, but I'm not convinced I'll never need to circumvent it to get something done, and I'm free to consider that a problem (along with other commenters, it seems). As I mentioned, I'm very happy using SQLAlchemy's lower level API. It's a helpful and elegant abstraction over queries and table definitions etc, and I've never needed to circumve…

sorry, I did a whole talk inspired by the term "leaky abstraction" and thought it was relevant.

Re: Lessons learned defying Joel Spolsky with Django

#149

Post by white_devil »

zzzeek wrote: post #148
white_devil wrote: post #143

Earlier quoted context omitted.

Look, I'm willing to believe that SQLAlchemy is the bad-assest ORM on the planet, but I'm not convinced I'll never need to circumvent it to get something done, and I'm free to consider that a problem (along with other commenters, it seems). As I mentioned, I'm very happy using SQLAlchemy's lower level API. It's a helpful and elegant abstraction over queries and table definitions etc, and I've never needed to circumve…

sorry, I did a whole talk inspired by the term "leaky abstraction" and thought it was relevant.

Is the talk's central idea that abstractions are bound to leak and we'll just have to deal with it? I did skim through the beginning of it, but then Youtube's player suddenly skipped to the end and stopped, and I moved on.

The thing is, SQLAlchemy's SQL Expression API is a suitable-level abstraction: high enough to be useful, but not high enough to guarantee leaks. I'm happily making queries with one-liners, and haven't had to circumvent it yet, but I bet I'd have run into trouble with any ORM already.

Re: Lessons learned defying Joel Spolsky with Django

#150

Post by iconfinder »

abs_farah wrote: post #90
iconfinder wrote: post #63

Earlier quoted context omitted.

We are posting a version with audio on our blog on Monday: http://blog.iconfinder.com

I look forward to it! Only audio, no video?

Here it is: http://blog.iconfinder.com/staying-sane-while-defying-joel-s...
Post reply on HN