I’m dealing with a sizable Django project housing crucial data, but the database structure lacks organization, with tables lacking proper relationships and relying on unique IDs. Additionally, the poorly written Django application is shared among three projects.
I’ve been tasked with creating a common central codebase – a Python package installable across all three projects. The goal is to manage common functionality centrally, while keeping application-specific parts separate. The admin panel, shared among the projects, will be moved to this package.
However, I’m facing challenges in making the package suitable for all three projects. While the model names are consistent, variations in field structures and the absence of relationship fields pose hurdles.
My current plan is to create a new project with a new database, restructuring the existing project. The new application will go live, allowing admins to access the old dashboards for checking legacy data. The plan involves a gradual migration from the old to the new database until the old project can be completely retired.
I’d appreciate feedback on this approach or suggestions for alternative strategies. I’ve opted for a new database to avoid jeopardizing the existing data. What are your thoughts on this plan, and do you have any alternative recommendations?
(content is optimised with ChatGPT, I am not this proficient in english. Also, I don’t really rely on AI response in this matter, Required a human response ;-))
<opinion>
Having a better idea of the current sizes of the projects (rough number of models and views and total lines of code) might alter some of these opinions - but I’ll share some general thoughts regardless.
First, I would want to understand the relationship between these different projects before deciding on a structural architecture, along with knowing the probable future for it in terms of additions and modifications and how the work is going to be distributed. (Is the same team going to be responsible for maintaining and upgrading all three projects? Or are the individual applications going to be distributed between teams? Do you have a stable staff, or a lot of turnover? Are there budget or management concerns for the intermediate or longer term?)
Note: I am not asking these questions expecting answers to them - I’m not in a position to evaluate your project or your organization. However, you should consider these factors when doing your redesign to understand the risks involved with a project like this.
If it’s a small well-coordinated team working on this project, I wouldn’t worry about separating that “central” component out as a package. I’d be thinking about creating one complete code base, perhaps divided into apps for the specific functional parts.
If the models are as poorly structured as you imply, then reworking the data model is a great start. Hopefully either you have a very comprehensive understanding of these applications or have someone available to you who does, to be able to understand the reasons behind why the original was structured the way it is.
Overall, I think you’re probably on the right track.
</opinion>