I'm trying to track user history using a DRF backend. For that, I've created a history table that will get a new timestamped row with each update. This model is a many-to-one and has a reference to the user model by a foreign key.
Here comes the confusing part. Every time I pull up the user profile, I would like to also pull the last entry into the history table. Thus, I am considering adding a couple of columns in the table which get updated with every insert into the history table since this is probably less expensive than performing a secondary lookup each time. I'd like some feedback on this approach.
Additionally, I'm slightly confused by how to perform this update/insert combination via a single API endpoint as DRF seems to only support one-to-one CRUD.
For illustrative purposes, I'd like to achieve the following via a single API view:
User hits API endpoint with access token and update values --> Insert history table --> update user table for user's row with inserted details
Thanks!
Related
I have a data model that consist in three models Profile, Company, Profession. Profile is a model that I am using in order to link a Cognito user with structured data (such as Company and Profession). Profile has a many-to-many relation with Company and Profession.
When we go to towards the AWS documentation it is clear that we need to create models and then create a new record on the join table amplify generates when we talk about many-to-many relations.
Nonetheless, the link above doesn't provide information to delete or update many-to-many relations. I assume that in order to update I need to delete the entry on the Join table and then add the new entries (so I avoid duplicated entries and make the job done)
But when I try to delete an entry from the join table I receive the following error:
Error of type "ConditionalCheckFailedException"
Going into the glossary of errors on DynamoDB I don't see which condition I may be created from my side unintended as the error suggest my condition is failing
In summary, in order to allow users to manipulate the professions on their profiles, I am trying to:
Add a new entry to the ProfileProfession table, and it works
But when I try to update by:
Delete previous entries -> This fails with the error above
Add new entries -> This works
In case of more context needed here a snippet of the important code I have: https://gist.github.com/duranmla/a8caf14f61ba25fd30610cdb470ee58f
Perhaps my code is not great but I just want to understand how this things work before move further. Thanks in advance to everyone for taking the time to read. ❤️
The answer was:
Yes, for many-to-many relations you need to manipulate the join Table
Yes, to update you need to remove or add entries to the join table
Also, the unexpected behaviour one get by seeing and then not seeing data that is persisted in DynamoDB, or Error ConditionalCheckFailedException one need to:
Check policies applied to the model
Understand how DataStore subscription works (I am currently DataStore.clear() on logout and DataStore.start() on signIn)
In my specific case once I did the following:
Create a Profile record on post user confirmation to tie the Cognito User to all other models I will have on Amplify Data Model
Update the authorization Policies on my Profile model (check image below)
Clean local data on user logout using DataStore.clear()
Start a subscription when user signIn using DataStore.start()
I was able to make things work as expected 🎉
An image of how the policies look like for Profile: https://i.stack.imgur.com/aqXxk.png
Allow any signed-in users authenticated with Cognito User Pool can Read, Update, and Delete Profile and Enable owner authorization while deny non owners to Update or Delete
Good resources to check:
https://docs.amplify.aws/lib/datastore/datastore-events/q/platform/js/#usage
https://docs.amplify.aws/lib/datastore/sync/q/platform/js/#clear-local-data
https://docs.amplify.aws/lib/datastore/setup-auth-rules/q/platform/js/#configure-multiple-authorization-types
I have an app where a user must be logged in to post an advertisement visible to others. How can I associate that person's unique id to that posting? Is there a way to fetch their attributes once they are signed in?
edit: each user submits a form to add the posting to the db.
I have the practice of putting triggers on every remotely important table.
Each of these tables includes 4 fields, date of insert, user who inserted, date of last change, user of last change.
Then the trigger just fills these fields with SYSDATE and APP_USER.
This way we get to see who inserted each data, and if it was later changed, we also see that.
For more important tables you should also have history, either the built in history, or a table into which each change is logged.
Each user will have a unique value in the :APP_USER substitution string.
I'm currently trying to build a web app that would allow many users to query an external API (I cannot retrieve all the data served by this API at regular intervals to populate my PostgreSQL database for various reasons). I've read several thing about ACID and MVCC but still, I'm not sure there won't be any problem if several users are populating/reading my PostgreSQL database at the very same time. So here I'm asking for advice (I'm very new to this field)!
Let's say my users query the external API to retrieve articles. They make their search via a form, the back end gets it, queries the api, populates the database, then query the database to return some data to the front end.
Would it be okay to simply create a unique table to store the articles returned by the API when users are querying it ?
Shall I rather store the articles returned by the API and associate each of them to the user that requested it (the Article model will contain a foreign key mapping to a User model)?
Or shall I give each user a table (data isolation would be good but that sounds very inefficient)?
Thanks for your help !
Would it be okay to simply create a unique table to store the articles returned by the API when users are querying it ?
Yes. If the articles have unique keys (doi?) you could use INSERT...ON CONFLICT DO NOTHING to handle the (presumably very rare) case that an article is requested by two people nearly simultaneously.
Shall I rather store the articles returned by the API and associate each of them to the user that requested it (the Article model will contain a foreign key mapping to a User model)?
Do you want to? Is there a reason to? Do you care who requested each article? It sounds like you anticipating storing only the first person to request each article, and not every request?
Or shall I give each user a table (data isolation would be good but that sounds very inefficient)?
Right, you would be hitting the API a lot more often (assuming some large fraction of articles are requested more than once) and storing a lot of duplicates. It might not even solve the problem, if one person hits "submit" twice in a row, or has multiple tabs open, or writes a bot to hit your service in parallel.
The following image shows a rough draft of my proposed database structure that I will develop for Django. Briefly, I have a list of ocean Buoys which have children tables of their forecast conditions and observed conditions. I'd like Users to be able to make a log of their surf sessions (surfLogs table) in which they input their location, time of surf session, and their own rating.
I'd like the program to then look in the buoysConditions table for the buoy nearest the user's logged location and time and append to the surfLog table the relevant buoyConditions. This will allow the user to keep track of what conditions work best for them (and also eventually create notifications for the user automatically).
I don't know what the name for this process of joining the tables is, so I'm having some trouble finding documentation on it. I think in SQL it's termed a join or update. How is this accomplished with Django?
Thanks!
Let's say I have two tables: Category and Product, and Product links to Category with a foreign key Production.categoryId == Category.id. I would like my database server to take care of counting number of products within a category using a denormalized field Category.productCount - the triggers will update this count on any update/delete/insert, so I don't have to worry about it. Is there a way to synchronize database-side triggers with Doctrine2 entities somehow? I really don't want to recalculate those counters on PHP side, as we are going to run it on multiple servers.
If I understand the question you want to be able to add a new product to a category, persist it then have Category.productCount update itself from the database? You can use
$entityManager->refresh($category);
To reload an entity from the database. I have not done it myself but I would expect that you could use the life cycle functionality to automate this.
But I do kind of wonder if it might not be better to just increment the counter locally without persisting it to the database. Let your trigger do the database operation but, within the request, update the count locally.