Earlier quoted context omitted.
Oh sweet summer child. Please read this carefully: https://folk.universitetetioslo.no/trygver/1979/mvc-2/1979-1... Business logic is supposed to be reused. Controllers in web frameworks (views in Django) expose no way to do it.
If you want to reuse logic you make another http request to the right endpoint.
Django Styleguide
61–70 of 141 posts
Re: Django Styleguide
#62> We use Celery for the following general cases: > > Communicating with 3rd party services (sending emails, notifications, etc.) > Offloading heavier computational tasks outside the HTTP cycle. > Periodic tasks (using Celery beat) Sigh. No mention of the trade-offs. There's simpler ways to do all these things. Celery is a big complex beast and it always pains me to see it as the default suggestion for simple tasks.
Do you have additional examples of those simpler ways? I totally understand how Celery can be a hammer and everything is a nail type situation.
Re: Django Styleguide
#63Earlier quoted context omitted.
> You can make subdirectories without making apps, and thus avoid dependency hell. It's hard to get 100% right and thus our projects always have a few lazy foreign key relationships and inline imports to avoid cyclical imports... but I think our code is easier to manage because we try to model the dependency relationships by having things in separate apps. > Also be wary of the formerly South, now built-in migrations…
I'm currently in circular import hell. My business logic has Jobs and Loads, and they both need to update each other under certain circumstances. Should these two things/monstrosities be lumped into the same app?
The long answer is if two entities are updating each other you might benefit from shifting all update responsibilities to one of them. Or even to a third entity that knows about both and keeps those two isolated from each other.
Re: Django Styleguide
#64Earlier quoted context omitted.
"Also be wary of the formerly South, now built-in migrations stuff. It's built around a fragile model (perfect history representation), so has lots of foot guns." My experience has been opposite so I'd be interested in hearing your experiences if you are willing. I have been using the built in migrations since day 1 on a medium sized Django project with 350+ migrations and migration issues for our project have been e…
Same here. If I was starting a non-Python project tomorrow I'd consider using Django to manage the database schema - especially now that we can describe custom indexes and constraints in migrations. Our project has gone thru over 1000 migrations so far tho we squash them down to 50 or so about once a year.
Re: Django Styleguide
#65I think there are too many concepts in this, but rather than being negative, here are some tips: Always keep your models slim. Don't stuff template related stuff in there. You need to look at those models often, so compact is a win. course_has_finished(course) is not much longer than course.has_finished(), and will allow you to expand the functionality as time goes on. Do precomputation if you need the information in…
> Always keep your models slim. As simple as possible, but no simpler. Django models are meant to deal not just with the data, but also with business logic. If `course.has_finished` is a property of the course, why would you want to have a separate function outside of the class? > Do precomputation if you need the information in a template If the precomputation is only needed in a template, you can (should, IMO) use…
My current preference is a functional core-imperative shell-style architecture where as much code lives in the functional core as possible. It's not very elegant with Django but it works fine. Cosmic Python (really accessible and fairly quick read if you have the time: https://www.cosmicpython.com/book/preface.html) has examples that are similar.
Re: Django Styleguide
#66Earlier quoted context omitted.
I'm currently in circular import hell. My business logic has Jobs and Loads, and they both need to update each other under certain circumstances. Should these two things/monstrosities be lumped into the same app?
The short answer is yes. The long answer is if two entities are updating each other you might benefit from shifting all update responsibilities to one of them. Or even to a third entity that knows about both and keeps those two isolated from each other.
Would that mediator be another app? Or should it be some module sitting in the project directory? (I'm not even sure Django would import something like that.)
Re: Django Styleguide
#67Earlier quoted context omitted.
> You can make subdirectories without making apps, and thus avoid dependency hell. It's hard to get 100% right and thus our projects always have a few lazy foreign key relationships and inline imports to avoid cyclical imports... but I think our code is easier to manage because we try to model the dependency relationships by having things in separate apps. > Also be wary of the formerly South, now built-in migrations…
I'm currently in circular import hell. My business logic has Jobs and Loads, and they both need to update each other under certain circumstances. Should these two things/monstrosities be lumped into the same app?
Re: Django Styleguide
#68Re: Django Styleguide
#69I've been working on a project with flask + sqlalchemy. I have those sql queries returning a bit of rows (up to 20k) and that are quite slow. SQLalchemy does not seem to support caching the results and I've started to use flask-caching[1] with redis using the @cache.memoize() decorator. Just wondering if I am taking the right path or if there is better alternative. [1] https://flask-caching.readthedocs.io
If complex, what does Sqlalchemy output as the SQL? Could you optimise the query? If quite complex, optimise the tables by redesigning them?
Was the move to allow Redis to cache persistently across requests? Does it do this?
Are you timing each function to look for slowness?
Re: Django Styleguide
#70Earlier quoted context omitted.
Same here. If I was starting a non-Python project tomorrow I'd consider using Django to manage the database schema - especially now that we can describe custom indexes and constraints in migrations. Our project has gone thru over 1000 migrations so far tho we squash them down to 50 or so about once a year.
Thats interesting, if I was using TypeScript to access the data, how would I keep the schemas in sync between TS and python?