I have two models in my django app: Schedule and Topic. I want to associate a Schedule with a sequence of Topics. This seems like a simple problem, but I'm blanking on it. What is the best way to do this?
I was going to use a ForeignKey in the Topic to refer to a Schedule, so it would correctly be a many-to-one relationship of Topics to a Schedule. But I also need to keep them correctly ordered, and I'm not sure how to do this. If the db wasn't involved, I would use a linked list, but I don't think that's the ideal solution here. Do I simply give each topic a field to track it's index within the list? I would be a little worried about loosing consistency, but I can probably update all of them at once.
Related
I am looking for suggestions on how to deal with a database table that has 1000 or more columns and I am tying to translate it into one or many Django models. The data also needs to be filtered through API calls within the URL. Every field needs to be able to filter the rest of the data.
I have come up with a few solutions and would like input or resources related to them:
Just have a model with 1000+ fields - This seems like it would be a nightmare to maintain and would require a lot of brute force coding but would likely work fine if data was selectively returned.
Use a JSON field to store all less frequently accessed data - The issue here would be difficulty in filtering the data using Django Filters.
Split data into related models connected by One-to-One relationships, as I understand this cuts down on join operations. - This would seem to require more coding than the first option but would be more maintainable.
Does anyone have any information or resources on dealing with database tables of this size?
You should absolutely split the model into multiple linked models.
Because of how Django models data in the database you should generally have a 1:1 relationship between models and tables, and your tables should be normalized to at least the third normal form.
I am working on my first django-viewflow project, and I have some very basic questions. I have looked at the docs and the cookbook examples.
My question is which fields go into the "normal" django models (models.Model) and which fields go into the Process models? For example, I am building a publishing model, so a document that is uploaded starts in a private state, then goes into a pending state after some processing, and then an editor can update the documents state to publish, and the document is available through the front facing web site. I would assume the state field (private, pending, publish) are part of a process model, but what about the other fields related to the document (author, date, source, topic, etc.)? Do they go into the process model or the models.Model model? Does it matter? What are the considerations in building the models and flows for separation of data between the two types of models?
Another example - why in the Hello World example is the text field in the Process model and not a model.Models model? This field does not seem to have anything to do with the process, but I am probably not understanding how viewflow works.
Thanks!
Mark
That's your choice. Viewflow is the library and has no restriction on data alignment. The only thing that needs to be done is the link between process_pk and the process data. HelloWord is the minimal working sample, that demonstrates a workflow.
You can put everything in the separate mode and provide an FK to in the Process model.
But the state field itself is the antipattern since eventually, you can have several tasks executed in parallel. And even sequential workflow could be constantly changed, new tasks could be added or deleted. You can have only published Boolean or DateTime field in the POST model to filter on that on the front end.
The general rule could be - keep all people workflow decisions in the Process model, and build all data models in a declarative way, keep separated workflow and actual data.
A little background. I've been developing the core code of an application in python, and now I want to implement it as a website for the user, so I've been learning Django and have come across a problem and not sure where to go with it. I also have little experience dealing with databases
Each user would be able to populate their own list, each with the same attributes. What seems to be the solution is to create a single model defining the attributes etc..., and then the user save records to this, and at the same time very frequently changing the values of the attributes of the records they have added (maybe every 5~10 seconds or so), using filters to filter down to their user ID. Each user would add on average 4000 records to this model, so say just for 1000 users, this table would have 4 million rows, 10,000 users we get 40million rows. To me this seems it would impact the speed of content delivery a lot?
To me a faster solution would be to define the model, and then for each user to have their own instance of this table of 4000ish records. From what I'm learning this would use more memory and disk-space, but I'd rather get a faster user experience as my primary end point.
Is it just my thinking because I don't have experience with databases? Or are my concerns warranted and I should find a solution as to how to be able to do the latter?
This post asked the same question I believe, but no solution on how to achieve it. How to create one Model (table) for each user on django?
I'm implementing a CQRS/ES solution with Akka.Net and Akka.Net.Persistence with a SQL Server Journal. So far everything seems to work great with the default sql-server plugin.
Last thing to verify was the ability to be able to reload/replay events from a specific AR, e.g. to rebuild a read model or to fill a newly implemented projection for a read model. The way I would go about this is reading the events from de DB and putting them on the eventbus or directly into the mailbox of the "projection actor".
I can't seem to find any examples of manually reloading events and besides querying the Journal table myself (executing sql query) and using the built-in serializer I'm basically stuck with this.
Is there anyone trying to do, more or less, the same thing?
Depending on your needs there are few ways:
Using PersistentView - it's a dedicated actor, which is correlated with some specific persistent actor, and it's able to receive it's events to build some different state from them. It's readonly. Pros: it's keeping itself up to date with events produced by peristent actor (however some delay between updates applies). Cons: it's related with a single actor, it cannot be used to aggregate event's from many of them.
Using journal query (SQL journals only) - it allows you to query journal using some specific filters. Pros: it can be used across multiple aggregates. Cons: it's not automatically kept up to date, you need to send subsequent queries to get updates. I'm not sure, if it has official documentation, but flow itself is described here.
PS: some of the journal implementations have their own dedicated serializers, but not SQL-based ones. And belive me, you never want to rely on default serializer for persisting events.
I'm building a small social site, and I want to implement an activity stream in a users profile to display event's like commenting, joining a group, posting something, and so on. Basically, I'm trying to make something similar to a reddit profile that shows a range of user activity.
I'm not sure how I'd do this in Django though. I thought of maybe making an "Activity" model that's OneToOne with their account, and update it through MiddleWare.
Anyone here have a suggestion? Away I could actually implement this in a nice way?
You pretty much need to use an explicit Activity model, then create instances of those records in the view functions that perform the action.
I think you'll find that any other more automatic way of tracking activity would be too inflexible: it would record events at the wrong level of detail, and prevent you from describing events in a way that the user wants to see them.
In my opinion, you should do exactly what you're saying, that is create the model Activity, which has a foreignKey to User which you will populate triggering the things you'll find 'interesting'.
This practice, even if redundant, will speed up your page generation, and you can add a custom field which will hold the text you want to display, and also you can keep track of what generate the Activity.