Hacker News new | past | comments | ask | show | jobs | submit login

> ORM is fantastic (and much more intuitive than SQLAlchemy)

Any articles or blog posts you can recommend to give some examples or comparison?

> entire Django ecosystem of apps that make heavy use of the model layer.

Exactly why I don't want to use the django system. I'm happy with the python ecosystem and have yet to find a django only module where no other alternative exist.

Its not that django is a bad web framework; on the contrary, to be honest. I'm just already invested in other modules that django decided to re-invent/design to fit their needs better.




> Any articles or blog posts you can recommend to give some examples or comparison?

Not really sorry, it's all personal experience.

> I'm happy with the python ecosystem and have yet to find a django only module where no other alternative exist.

What about all the cases where you need support from database schemas? For example let's say you want to have access to Stripe subscriptions from Python and cache them to your database, you'll need something like dj-stripe. There's nothing "in Python" other than an API client because the Python stdlib doesn't have a model ORM.


> For example let's say you want to have access to Stripe subscriptions from Python

I will use the official stripe flask checkout example[0].

> and cache them to your database, you'll need something like dj-stripe. There's nothing "in Python" other than an API client because the Python stdlib doesn't have a model ORM.

With their OpenAPI definitions[1] to create the needed sqla model boilerplate, which creates the needed pgsql tables. For change log of my models it is kept in my py model files and xml with sql diff using a cheat where I implemented a Liquibase python wrapper[3].

I'm lucky where I work in a not to enterprise env so self-rolled solutions is sometimes acceptable and we try to keep it sane.

[0]: https://stripe.com/docs/checkout/flask

[1]: https://github.com/stripe/openapi

[3]: https://github.com/Morabaraba/python-liquibase


> I will use the official stripe flask checkout example[0]. [...] to create the needed sqla model boilerplate, which creates the needed pgsql tables

Ok, so let's say someone else wants to apply this pattern (it's extremely common after all). Should they do the same thing as you did?

Should the next guy as well? Where does it stop? At some point, you write a library right?

Well that library will end up containing the ORM models. So your choice ends up being between "I will roll my own models" (whether they're autogen'd from openapi or not doesn't matter) and "I will use someone else's models". You're back at exactly the same point as earlier, none of this actually achieved anything, other than give you extra work.

The point I was trying to originally make is that saying you'll do it "in pure Python" instead of "in Django" doesn't actually work. If by "Python" you mean "SQLAlchemy" that makes more sense.

At the end of the day, I wish the Django ORM were ripped out of Django so we could have libraries that depend on Django's ORM without them depending on the entire Django stack. There's also a lot of demand for the other side of this, which is having Django's ORM be replaceable by SQLAlchemy. Then you're no longer talking about "Django vs Flask", but "djangorm vs sqlalchemy".

The final step after this would be to have the Django ORM support SQLAlchemy's model declarations. The Django and SQLA model declarations are already very similar. Then we live in a world where you can swap out the ORM API at the application layer, but have libraries that are compatible with both and don't need to be reimplemented for both Django and SQLAlchemy. (I strongly believe the distinction between the two model APIs is not useful right now due to how similar they are)


> Should they do the same thing as you did?

They can, I recommend they look at the swagger-codegen[0] api stub templates. There clients as well.

[0]: https://github.com/swagger-api/swagger-codegen/tree/master/m...

> At some point, you write a library right?

Normally a flask-ext forms around a established python library. Yes now we are back at the tight integration problem, but at-least your knowledge of the py library will not be lost in another eco-system.

> I wish the Django ORM were ripped out of Django so we could have libraries that depend on Django's ORM without them depending on the entire Django stack... Django ORM support SQLAlchemy's model declarations... Then we live in a world where you can swap out the ORM API at the application layer, but have libraries that are compatible with both and don't need to be reimplemented for both Django and SQLAlchemy.

Amen Brother!




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: