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

SQLAlchemy 0.9.0 Released

sqlalchemy.org

Post reply on HN
Print view View original

21–30 of 43 posts

Re: SQLAlchemy 0.9.0 Released

#21

Post by [deleted] »

yareally wrote: post #7
auvrw wrote: post #4

a really solid, perhaps unique, library that, as far as i can tell, completely addresses the "impedence mismatch" argument. if you're directly using a database api in a structured way, you've probably already reimplemented the sqlalchemy core, and refactoring your program to use sqlalchemy will give you an orm, should you want one, and make your code portable across database implementations even if you don't. if you'…

> i really wish there was something like sqlalchemy for java. Ebean[1], perhaps? I've only used it for a project in Play 2.0 that was built on Java (it's built into Play 2.0), but it was far less painful compared to other Java ORM libaries like Hibernate. [1] http://www.avaje.org/ebean/getstarted_props.html

[deleted]

Re: SQLAlchemy 0.9.0 Released

#22

Post by Edmond »

auvrw wrote: post #4

a really solid, perhaps unique, library that, as far as i can tell, completely addresses the "impedence mismatch" argument. if you're directly using a database api in a structured way, you've probably already reimplemented the sqlalchemy core, and refactoring your program to use sqlalchemy will give you an orm, should you want one, and make your code portable across database implementations even if you don't. if you'…

You could also check out Crudzilla (crudzilla.com), it has a middleware that simply allows you to specify your SQL and forget about everything else. Includes a bunch of other goodies that'll make web development a pleasure :)

Full disclosure: Founder.

Re: SQLAlchemy 0.9.0 Released

#23

Post by reactor »

babs474 wrote: post #15
auvrw wrote: post #4

a really solid, perhaps unique, library that, as far as i can tell, completely addresses the "impedence mismatch" argument. if you're directly using a database api in a structured way, you've probably already reimplemented the sqlalchemy core, and refactoring your program to use sqlalchemy will give you an orm, should you want one, and make your code portable across database implementations even if you don't. if you'…

I find Jooq to be similiar in some ways. http://www.jooq.org

http://www.querydsl.com/ as well.

Re: SQLAlchemy 0.9.0 Released

#24

Post by tga »

scardine wrote: post #18
megaman821 wrote: post #14

Thanks for this release. Learning SQL before ever touching an ORM, SQLAlchemy's approach makes a lot more sense to me than something "simplier" like Django's ORM. Anyone know, is there any chance Django would pull in SQLAlchemy core as a dependency and implement their ORM on top of it?

The ORM is mediocre compared to SQLAlchemy, the template system is weak compared to Jinja2. If you swap Django's ORM with SQLAlchemy and replace Django Templates with Jinja2, you end up with something like Flask. The killer feature for me is Django's "admin" app. When I'm not using the "admin", the rest of Django kind of gets in the way. Nowadays I prefer a less opinionated framework like Flask if I'm not using the "…

In my experience the true killer feature of Django is the "batteries included" approach. If you stay within the boundaries of the framework you get a standard project structure, a decent ORM, a template language (dogmatically crippled, but that's a different discussion), a forms handling library, and the typical assorted framework toolkit (internationalization, logging, development server, utilities, etc) -- all equally documented and maintained. Compare this with having to choose and figure out individual libraries for every one of the things above, each coming with different levels and styles of documentation, communities, and resources.

The end result is that you spend less time deciding on small things and can just use what's in the box. The real value is that the next person working on the code is already on the same page and can start working with it a lot quicker.

Re: SQLAlchemy 0.9.0 Released

#25

Post by tga »

megaman821 wrote: post #14

Thanks for this release. Learning SQL before ever touching an ORM, SQLAlchemy's approach makes a lot more sense to me than something "simplier" like Django's ORM. Anyone know, is there any chance Django would pull in SQLAlchemy core as a dependency and implement their ORM on top of it?

I don't see this ever happening because Django has no dependencies on any other Python libraries. It wouldn't make sense to start requiring SQLAlchemy only to reimplement the existing ORM on top of it for little to no benefit.

Re: SQLAlchemy 0.9.0 Released

#26

Post by megaman821 »

scardine wrote: post #18
megaman821 wrote: post #14

Thanks for this release. Learning SQL before ever touching an ORM, SQLAlchemy's approach makes a lot more sense to me than something "simplier" like Django's ORM. Anyone know, is there any chance Django would pull in SQLAlchemy core as a dependency and implement their ORM on top of it?

The ORM is mediocre compared to SQLAlchemy, the template system is weak compared to Jinja2. If you swap Django's ORM with SQLAlchemy and replace Django Templates with Jinja2, you end up with something like Flask. The killer feature for me is Django's "admin" app. When I'm not using the "admin", the rest of Django kind of gets in the way. Nowadays I prefer a less opinionated framework like Flask if I'm not using the "…

I don't think Django should ditch their ORM, but for the time being simply re-implement it on top of SQL Alchemy core.

I think it would have at least three positive outcomes:

* It would greatly increase support for the number of databases and database drivers.

* It would give developers something in between using the ORM or forgoing it and using SQL strings in raw() or db.connection().

* It would provide an easier path forward to adding additional capabilities into the Django ORM.

Re: SQLAlchemy 0.9.0 Released

#27

Post by goostavos »

auvrw wrote: post #4

a really solid, perhaps unique, library that, as far as i can tell, completely addresses the "impedence mismatch" argument. if you're directly using a database api in a structured way, you've probably already reimplemented the sqlalchemy core, and refactoring your program to use sqlalchemy will give you an orm, should you want one, and make your code portable across database implementations even if you don't. if you'…

This might be a "LMGTFY" type question, but having never used SQLAlchemy, what sets is apart from something like Hibernate?

Re: SQLAlchemy 0.9.0 Released

#28

Post by megaman821 »

tga wrote: post #25
megaman821 wrote: post #14

Thanks for this release. Learning SQL before ever touching an ORM, SQLAlchemy's approach makes a lot more sense to me than something "simplier" like Django's ORM. Anyone know, is there any chance Django would pull in SQLAlchemy core as a dependency and implement their ORM on top of it?

I don't see this ever happening because Django has no dependencies on any other Python libraries. It wouldn't make sense to start requiring SQLAlchemy only to reimplement the existing ORM on top of it for little to no benefit.

That's not true. Django doesn't install any other libraries. It simply includes them in Django itself, like simplejson or six.

I think the packaging and setup tools are getting better so maybe it doesn't always have to be that way.

Re: SQLAlchemy 0.9.0 Released

#29

Post by psgibbs »

mwhite wrote: post #16
Demiurge wrote: post #11

how does SQLAlchemy support for PostGIS compare to GeoDjango ORM?

Looks like it's pretty robust: http://www.geoalchemy.org/tutorial.html

It is, though if you're using PostGIS, I'd recommend GeoAlchemy2[1], which ties into SQLAlchemy a bit more naturally (because they get rid of support for all other engines). Also, seems to be more actively developed/maintained.

[1] https://geoalchemy-2.readthedocs.org/en/latest/

Re: SQLAlchemy 0.9.0 Released

#30

Post by tga »

megaman821 wrote: post #28
tga wrote: post #25

Earlier quoted context omitted.

I don't see this ever happening because Django has no dependencies on any other Python libraries. It wouldn't make sense to start requiring SQLAlchemy only to reimplement the existing ORM on top of it for little to no benefit.

That's not true. Django doesn't install any other libraries. It simply includes them in Django itself, like simplejson or six. I think the packaging and setup tools are getting better so maybe it doesn't always have to be that way.

I see what you mean, but arguably those aren't really dependencies if they are included in the Django tree. Also, it's definitely not something that would work with a large library like SQLAlchemy.

You can also see the "no dependencies" claim on the Django website: https://www.djangoproject.com/download/, it's a selling point.

Post reply on HN