Get the Current User

No, actually I would disagree with that. Trying to figure out everything you’re going to need from your models at the very beginning generally doesn’t work. There are going to be changes and refinements over time in any non-trivial system.

The real issue is whether or not your environment can handle the changes, and that’s where migrations shine.

Right now, I’m working on a system with 194 models (I just checked) in the primary database. We have had more than 100 migrations built over the past two years. (I can’t give a precise number because we have, on a couple of occasions, collapsed migrations to reduce their number.)

Yes, there were some general plans laid out at the beginning regarding what tables were going to be needed, but what we didn’t try to do was identify all the columns in each. Those came out as part of the natural evolution of the system and identified during development. There was no way we could not plan on changing tables during the project.

We’ve added, removed, and renamed both tables and fields over time. We’ve changed data type of fields. We’ve even moved fields from one table to another. Those sorts of changes are just all part of working through a significant project when you don’t know exactly where you’re gong to end up once you get started.

And yes, migrations is one of the most significant reasons why this all works so well for us.

Don’t fight change - embrace it, but, learn how to manage it using the tools at your disposal.

Ken

I agree I really meant just getting the basics layout down first and be sure of how tables are related. I think the MOST important lesson to learn here is, I should learn Django more and learn how migrations work in detail, so I am not stuck with errors like column not found.

A side question: Do you know flask and how do you think it compares to Django?

Your project sounds massive. When do you think you’ll be done?

<opinion>
Flask vs Django - Flask is a great project. It does a lot of things very well without getting in your way.

It’s almost an apples-to-oranges comparison. Django provides a lot of features that aren’t baked into Flask. As a result / side-effect of that fundamental difference, you have a lot more flexibility in Flask that is not easily available in Django. Which is important if that type of flexibility is important to you. To us, it’s not.

I got into this in a lot more detail in this thread, Should I use Django?, but the Reader’s Digest version is that over the past (almost) 5 years, we’ve migrated all our projects from Flask (and a couple other smaller projects in Bottle) to Django

</opinion>

Regarding our core project - we’ve hit the MVP milestone, but this is the type of project that is never “done”. The project it’s replacing was live and under active maintenance for about 10 years. (It’s one of those core-corporate type projects that can live forever.)

@KenWhitesell After hearing about the size of your project, I’m curious: Is that code open to the public or private within the company? I interned at a company for three years where I learned Django from the ground-up and developed a codebase ~30k lines in size, but I’ve never seen a project to that magnitude. I have a huge passion for this framework so any senior-level, complex development that I can get my eyes on is beneficial :slight_smile:

Hi Ken yes Django provides a lot more out of the box functionality and I think the admin section that is included is a huge bonus. I like Flask though exactly for its flexibility but I think I lack the experience to be able to use it (and Django of course) to its full capabilities. More studying to do is all I can say.

Your project sounds really intriguing and really big. Would love to see it the day it’s done. The project I want to develop is also on the never done category, so I see myself busy for a few years with it.

Best of luck and again thanks for the opinion and resource.

Answering both sets of questions here -

  • Yes, it’s internal and not something I can share.

  • Right now, not counting the Django-generated files (migrations and inspectdb output) it’s also just about 30K lines of code, but it’s heavily ‘meta’ and table/data driven. (Very few constants of any kind are hard-coded, even some forms are dynamically created from data.) It’s got some technical intricacies, but really, most of the code exists to examine the data and figure out what needs to be done next, in a very dynamic and fluid situation. It’s built this way to allow us to maintain one code base while deploying it in multiple similar-but-not-identical environments.