Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 4 years ago.
Improve this question
I need something to view the queries happened ( creating or updating or deleting ) in DB tables in Django, I want it to be able to be used by the user, not at the admin panel
If I understand your question correctly, you are looking for a model history (sometimes also called "audit trail").
In this link there is a comparisson of different packages that can be used for audit/history of models.
As I already pointed out in this answer,
I use django-simple-history which comes with a nice integration to view the list of changes of every model instance in the admin.
For my use case at least, django-simple-history provided me with what I needed, and so far I did not face any issues with it, even though this package does NOT track history of ManyToManyField (for that see related questions like this or this or the Github issue).
Now, if you want the end user to be able to see the history (but not through the admin panel), then you would need to add a few pages for that.
For example, you could add a list view for each model using djangos generic ListView.
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 5 years ago.
Improve this question
I want to build a web application using Django. Basically a CRM for specific business type. Lets say it's for Gyms for this explanation. I will have multiple customers. The customers will each get their own 3rd level domain name. Like golds.gym.com and 24hrfitness.gym.com. Each customer will have their own customers that will use the site as well. I want to allow overlapping usernames across sites, but unique to each site. I would also like to use the built in admin pages, but I will need to be sure that the admin pages are site specific.
My question is more or less, "Is this possible". But I think what I really want to know is "Is this possible using something built in or something someone else has out there for Django?"
I have looked at the sites framework documentation and that seems to be what I need, however I have not found any documentation on how to make the admin and the users site specific.
You can definitely do it with the sites framework, but it does take a significant amount of bootstrapping. This also goes under the assumption that you will use a different hostname for each site, as this is how the sites framework works.
When you use the sites framework, there is middleware available that automatically populates the ID of the site on the request object.
If you want the end users to be able to use the admin section and see ONLY the objects on their account, you will need to have an account foreign key for every model.
You could then do something like overriding get_queryset in your views to automatically exclude any objects not belonging to the account.
Of course, you would also need a custom user model so that you can link users to sites.
If you are using postgres you could consider checking out Django Tenant Schemas, which accomplishes multi-tenancy using native postgres schemas.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
I wonder if a good habit is to have some logic in MySQL database (triggers etc.) instead of logic in Django backend. I'm aware of fact that some functionalities may be done both in backend and in database but I would like to do it in accordance with good practices. I'm not sure I should do some things manually or maybe whole database should be generated by Django (is it possible)? What are the best rules to do it as well as possible? I would like to know the opinion of experienced people.
It is true that if you used a database for your business logic you could get maximum possible performance and security optimizations. However, you would also risk many things such as
No separation of concerns
Being bound to the database vendor
etc.
Also, whatever logic you write in your database won't be version controlled with your app. Thus, whenever you change your database, you will have to create all those things once again.
Instead, use Django ORM. It will create and manage your database based on your models by itself. As a result, whenever you recreate your database, you will just have to run migrations with one single command and you are done.
This will cover most of the situations. And whenever you will need those speeds of stored procedures, Django ORM has you covered as well.
In short, I believe that business logic should be kept out of the database as much as possible.
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 8 years ago.
Improve this question
I am learning about Django & Python from past two weeks.though, my reading i came across models.py & forms.py. structure of both this is almost same. can anyone explain me whats the difference between them?
I also want to know where do i have to write the (<form> </form>) code. I mean in any html file or *.py file or where?
They are indeed very different in concept, albeit they can look similar. Let me explain:
Models define your business objects and data structures. They are the "entities" of the application wich have to be persisted in the database. Since it's a definition of the objects and their attributes, you define "fields". They represent the data structure and persistence of the app.
Forms are meant to make easier to get input from the user, validate data, render html and recover values supplied by the user. They also have fields but you have to note they don't map to a database and they don't represent an entity. They represent the "inputs" of the app.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 9 years ago.
Improve this question
Is it possible to use only some features of Django?
I'm using my own home-made ORM with redis for a webapp using the MVC model. Now I want to know what I have to do to so that I can take advantage of Django's very nice admin.py
Has anyone ever done anything similar?
You can "use only some features of Django", but some parts depend on other parts. Django Admin is very dependent on Django ORM. It is basically a tool for visualizing, creating and editing Django ORM models. Using it with your own "home-made" ORM is virtually impossible.
Take a look at django-nonrel. It forks Django to provide support for non-relational databases (currently MongoDB and Google App Engine). It might help you if your main aim is to use a non-sql db in your project. It still won't help you to easily integrate your custom ORM with Django Admin. So your other option is to write your own admin for your project.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 9 years ago.
Improve this question
to get posts for a user:
GET http://test.com/users/123/posts or GET http://test.com/posts?user_id=123
to get new posts count:
GET http://test.com/posts/count/new or http://test.com/new_posts_count or others?
This is a good read: http://www.vinaysahni.com/best-practices-for-a-pragmatic-restful-api.
And in terms of the two formats you suggested: I prefer the former.
Doesn't matter from a REST point of view (REST doesn't define URI structure). The client should not know the URL structure before hand so technically it doesn't matter to the client either.
I personally prefer the first style as I think it makes more sense when you have a resource hierarchy. It also allows a client to move back up a URI by simply chopping off the end resource, similar to how you can go back up a directory on a file system by simply clicking the parent button.
But there is no "right answer" to this from a REST point of view. REST is concerned with the transfer of state of resources, not the resource hierarchy or URI definition.