In my project, there are applications named "developer" and "startup"
In developer and startup application, i need a table named "languages", which implies that the language developer use and startup use.
So i made model named "languages", But I'm thinking about whether to make this in developer application or startup application, or make a new application and make it in it.
When I made it in developer application, i could use it by importing startup application models.py. But actually, I don't think that the table "languages" is more relevant to application "developler" than "startup".
How should I do?
I referenced link https://stackoverflow.com/questions/4137287/sharing-models-between-django-apps
As far I can see from your context: the language model (If even needed) should go to the developer because the developer is the one who closely relates to language, and will mostly consume it in views, and serializer, etc.
In general, we follow these three basic rules
Keep apps small Each app
Does one thing well
Keep apps separate so they can be exported and used elsewhere
Just keep these simple basic rules in front of yourself whenever defining a new model in a Django app.
Related
I recently made an online-post-curating service with django. I now upload posts manually everyday but finally realized web-crawler/scraper is highly needed to save my time. In this case, is it better to make a separate django project(for the crawler only)? Or just starting a new app in the existing project is enough?
[Advantage/Ground of making separate project for crawler (I guess)]
Totally different dependencies needed, so new project
Mainly asynchronous tasks unlike the existing service
The function is very universal (not really related to post-curating service)
Server spec. for crawler must be different, so be prepared in advance with separate project.
[Opposite side - making an app is inough]
For asynchronous tasks, just adding some library like Celery in your project is enough
Running multiple projects demands lots and lots of additional effort
Two projects using one database(saving and reading posts) at the same time can be a threat in some day
Sorry for the tacky question and thank you in advance!
I've been reading through related articles regarding using same database for multiple django projects however, I have not been able to come up with a fix yet.
I've tried relative and absolute pathing when importing but it gives "attempted relative import beyond top-level package" error when I try to access parent directory.
Project 1 gets the users to write to database by filling in a form and Project 2 retrieves data written in by users from database.
I'm using Postgresql for database. I've tried writing exactly same models.py for both projects but it seems like in database they appear as separate relations/tables. E.g. for table named school in both models.py, it would look like project1_school and project2_school in Postgres database.
Is there a way to write to and read from same tables of same database?
Thank you so much in advance.
I think that you might be confuse with the difference between Projects and Applications.
Projects vs. apps
What’s the difference between a project and an app? An app is a Web application that does something – e.g., a Weblog system, a database of public records or a small poll app. A project is a collection of configuration and apps for a particular website. A project can contain multiple apps. An app can be in multiple projects.
Writing your first Django app, part 1
So in you particular case, I would say that your actual projects, both of them, could be applications of one project. The main reason, why I think this is a better approach, is that both are gonna use the same data, one application writes while the other retrieve it. One could even argue that they actually could be the same application. But this may depend on many factors of your business.
BTW, is really hard for me to imagine a situation where it would be a good idea to have two projects using the same database. Even if both projects need to share data, I would not think in using on database. I would try to solve it at an application level. But I you need for some reason to share information at database level, there are tools to connect both databases.
I have two Django Projects that have different use cases. There are reached using different domains. They are hosted in two different servers. Also each Django project has it's own database.
Now, both the projects have some models and some business logic common between them. I don't want to duplicate the code and data which shall be chaotic going forward. Also, I want the models and code (business logic) to be in sync (when models/code is altered).
Can anyone guide me towards a pattern that can help me attain the required architecture: 2 separate projects with common models and business logic.
Thanks in advance.
I've done this before. You will have to move the shared models and business into a new python package (better if you can create a django app that encapsulates these models), in a separate directory.
Add this directory to your python path (the one that contains the package, not the package itself) and you should be able to use this code from within your projects.
The only downside to this is having to configure PYTHON_PATH in your servers or having to copy manually this package into your runtimes
More specifically, when using a backend application framework I generally am afforded some level of asset management which allows me to work with multiple files in development which are uncompressed and unminified and then in production mode those files become automatically minified, compressed, and concatenated into a single file.
I am looking to create an Ember application that is a single page app that interfaces with a separate RESTful services layer. I simply do not need the weight of a framework behind the Ember app and am hoping to serve it as static html+css+js, so I am looking for any guidance on how to easily manage development and deployment of a client-side only app without adding much overhead.
Right now my biggest issue is with including JS (and to a lesser extent, CSS) files. My HTML is static and I have an Ember app comprised of many files, so I have many script tags to include them all. This is clearly not appropriate for production so I imagine some kind of build tool will be needed to assemble my Javascript files and overwrite the script tags in the HTML file. Are there tools out there right now that will do this? Is there another approach that I may be overlooking?
This is my first fully client-side application so it's very possible that I just need to make a paradigm shift, having done server-side applications for so long.
Agreed this can be tricky without a backend framework. For sure script tags are not the way to go and you will need some kind of build tool for production deployment.
Ember App Kit is a solution a few of us have been working on. It's still early stages but i've used it for a couple of projects so far and it's been much better than trying to roll-my-own with grunt. I would expect it to become the default starting point for ember apps in near future, to try it now just download it as a zip then read the Getting Started Guide
There are many other solid solutions out there, consider checking out:
ember-tools
brunch-with-ember-reloaded
brunch-with-hapmsters
charcoal
I use a combination of requirejs and Grunt, using these lovely functions and this one, which can compile your ember-handlebars templates into functions. (The git-contrib includes the ability to watch for changes in your files and perform various build steps which may differ if you are in development or production. You can have separate grunt functions which run various tasks for production or development. Of course for all of this you are going to need node!
We're thinking of bringing in a couple of specialists for short-term projects. I'm trying to figure out how to allow them to effectively develop against our code base without releasing the whole code base to them.
Each project has well defined areas they need access to; primarily our main models, together with specific pieces of our app.
We've started to do a better job of breaking up the project into multiple apps within a single django project, but they all still live together in a single git repository. If you check out the repository you get everything.
What are successful strategies for arranging code and repositories such that third parties can access core models and selected functionality without having access to everything?
Note that since this is a somewhat rare need, I'd strongly prefer a setup that doesn't inconvenience our core developers - their lives should be minimally impacted by the setup.
You might try git-submodule as a way of developing each app as its own git repository while still letting developers grab the root and all apps with one "git clone". It's not totally painless though since when you do this any changes to a submodule will need to be committed there and then again in the root repository to reference the new submodule commit. This is probably inescapable, since if you want anyone beside a core developer to be able to commit to an individual app then the app's commits must be independent.