I'm fairly new to Django having up to this point used to it display data from other sources.
I'm embarking on a new project and have a query about the way Django handles model relations (did some searching couldn't find much for this specific instance) and am wondering the most efficient way of accomplishing it.
I have 3 Models, User(obviously :S), Project and Report. Now a report is part of a project and done by a user but project is also 'owned' by a user. In that other users cannot see either the reports/projects of another user. Do i need two foreign keys for Report or just one (e.g User creates projectA and Report1, since Report1 is linked to Project it is also linked to User) ie:
Class Report(models.Model):
user = models.ForeignKey(User)
project = models.ForeignKey(Project)
or
Class Report(models.Model):
project = models.ForeignKey(Project)
If a report is only associated with a user through the project (this means specifically that it makes no sense to have a report with a different user than its project) then the second one is better. You will always be able to access the user by (report object).project.user, or in search queries as 'project__user'. If you use the first one you risk getting the user data for the report and the project out of sync, which would not make sense for your app.
Related
I am developing a system where the user have forms to fill and this info is stored in a database. In one of the screens I have the following flow:
Inside a project he can add multiple orders.
Each added order opens a configuration screen which internal information of the order can be set. Also it is possible to add items to the order.
Each added item opens a configuration screen that allows user to set internal informations.
To sum up, the flow is Project -> Order -> Item, where "A -> B" means A contains 0, 1 or more Bs.
This project is being developed using WPF with Entity Framework to manage the database access. I am binding entities from Entity database mapping directly into the screens. This way we have some "advantages" with WPF, as not null fields are painted red, for example. Moreover, the code is much simpler. The entities are only updated (or added) to the database when the project is saved. Therefore, items can be edited, then orders can be edited and they are only saved when the project is saved, since they are dependent of the project ID to be saved.
However, using mapped entities directly has a huge problem: let's say the user edits an Item inside an Order. Then, he edits it again, but this time, instead of pressing "OK", the user presses "Cancel". The changes must be reverted. However, the previous state was lost, since it was not updated in the database and were changed because of WPF binding.
What is the best approach to prevent this problem? I don't know if creating clones work well in Entity Framework. And creating variables that only transfer their values to the object when the confirm command is clicked would be against the MVVM pattern, and would make me lose the "advantages" I have already talked about.
Please help me!
Thanks!
I'm developing an open-source web application (a helpdesk) where the users will download it and install. This application will have some settings like: title, colors, default e-mail, logs... (for example). This settings will be edited by the user on the admin panel because most of them will not understand how to do it in code.
My question is what is the best way to store this on a (MySQL) database model? And counting that this application will upgrade and add more "settings" to that settings table.
Thank you in advance
There are a lot of different ways to do this, and it depends on what you think the final needs will be.
There's nothing wrong with saving parameters in a dedicated table, each parameter/user/value on a separate row. This is a fast way to set and get the information, and allows you to easily get access to reports by parameter and value and user, for example, what colors are the most popular.
If you are just using this for configuration, you can store the parameters as an XML or JSON string in a text/blob field. This has the benefit of giving you a single load to get all of the parameter values. Even more powerful, if your application already has default values for the parameters, you can easily extend the application without changing the database records. For a large number of parameters, this reduces the number of DB calls to load up all the parameters.
I have several customers, each running a customized version of my ISQL (SE) desktop app. I would like to replace their desktop app with thin client WinTerm's, connecting to the cloud (My ISQL app on an SuSE Open or RedHat server). If this can be done, I would like for each customer to use one standardized version of my app to simplify updates and support. However, I'm not sure what's the best way to design the database. Should each customer have their own database.dbs (DBPATH=) or is there a better design?
You have two options, one of them that you've already considered:
Each customer has their own database with the standard name.
Each customer has their own database with a separate name for each.
The advantage of option 1 is that your existing code would work substantially unchanged; you'd simply have to ensure that the setting of DBPATH is correct for each customer. The downside is that you need to create a separate directory for each customer too. However, this has its merits; you can probably more easily keep Customer A from seeing any of the files generated by Customer B (and vice versa) if each customer has their own separate home directory, and their database is located in that directory.
The advantage of option 2 is that you can put all the customers' databases in a single directory. As mentioned, this is apt to make it easier for Customer A to see stuff that he should not see that belongs to Customer B. You would also have to ensure that you override the default database name every time you run a command - whether that's sperform or sacego or anything else.
Between the two, I would go with option 1 (separate databases with common name in different directories), with rigid walls between customers. Each customer would have their own user name and group, and the permissions on the directories would avoid public access of any sort. They can all still use a single INFORMIXDIR and your associated forms and reports.
in our corporate directory users can search for their coworkers. Results are then displayed in a table-like layout on a plain HTML page (the backend is PHP if that's any matter). The list is limited to 25 entries.
Now the request has come up to show the presence status from Microsoft Lync next to every entry in that list. Creating a tiny Silverlight application to represent the status of one single person is quite easy, placing it to the left of each name is also.
This way of doing it will of course result in up to 25 almost-identical Silverlight objects beeing created and then accessing the Lync client API.
Another way to do it would be to place the complete listing inside a (more complex) Silverlight application, so that there wouldn't be but one instance on the page. This would also cause quite some extra development work.
The question: Is it considered bad practice to create 25 instances of the same Silverlight object on one single web page?
Thanks for any input or opinion you can give,
Patrick
If you're using this in an internal corporate environment and getting the finished product out quickly is important then you're likely fine. Each Silverlight object will need to query the Lync status of each employee so that may be a deciding factor in terms of performance.
Alternatively, it wouldn't be all the difficult or labor intensive to create a simple single user control representing a single user's Lync status and then display all inside of a single Silverlight app.
We're investigating using RIA Services (July 09 Preview) to expose parts of an existing EF model. We've added a Domain Service class to our web application and specified the EF model to use and selected a few of the entities we wish to make available via the domain service (some have editing enabled, most do not).
We build and everything is great, but if we want to add an additional entity to the domain service how do we do that. Is it a case of delete your current class and re-add and this hole will be plugged when RIA Services hits RTM?
I agree, that's annoying to type in all that manually every time the DB changes. What i end up doing is creating a new temporary domain service classes (and metadata) and cut&pasting the code into the existing domain service and then removing the temp service from the project.
Another option can be (didn't try it) to make the generated file a partial class, put all the new queries into a separate file and every time the DB Schema changes just blow away the generated file and recreate it using the wizard. Just a thought
You can just add the code for the new entities... just add the right methods, query, and depending on which operations you need, insert, update, delete and custom ones.
Yoiu shouldn't have to delete your current class, which theoretically contains a bunch of interesting app logic (I'd imagine) just because you want to add an entity.
My solution to this problem was to create a code snippet that does most of the work.
I only have to type efdsmethods, tab twice, and replace the EntitySet name, EntityType name, and entity variable for the methods to use and then I'm done. It makes adding the 4 standard methods very easy.
I've submitted my snippet as a patch (#10154) to the Silverlight Contrib project on codeplex, but it hasn't been accepted yet. Until then you can download the snippet from here.
Hope this helps you.