I want to show a different option to the user in workflow through input node, depending upon whether the user has modified the record or not.
Problem is if I would use a condition node with custom class to detect whether object has been modified by some person or not in between the workflow process then as soon as the person clicks on route workflow the save is automatically called and isModified() flag gets false, How do I get in condition node whether some person has modified the record or not.
I have to show different options to the user if he has modified and different option on routing workflow if he have not modified.
Sounds to me like you need to enable eAudit on the object and then to check whether eauditusername on the most recent audit record for that object bears the userid of the current user.
It's a little hokey and tempts fate, but if your condition node is early in the workflow's route when this button is pressed, you could try and check to see if the changedate on the object (assuming you are working with one of the many objects that has one) is within the last 5 seconds. There is a gap where the record could be routed twice within a few seconds, but the gap is fairly hard to hit. There is also a gap where if the system slows down at that point and takes more than 5 seconds to get to and run your condition, then it would appear to be not modified. You can play with the delay to find a sweet spot of the fewest false positives and negatives.
Related
There are 10, 000 users. Each can define up to 500 conditions for an enterprise supply chain inventory.
An example of a condition could be
Group1
Item in InventoryX > 5000 AND colourItem == Red
AND Group2
Item in InventoryY > 4000 and colourItem == Green
Whenever the state of the database (single row in InventoryX, InventoryY, and colourItem columns) meets to the condition mentioned above, the user who has created the alert should be notified.
The first solution that comes to mind is to continuously keep polling the database, at a given time interval (say 1 minute) but the problem with it would be every minute there will be 10000 X 500 polls.
This is difficult to scale.
We also need to keep in mind that the user's are given a simple front-end to create conditions, and they can update these conditions as per their whim. No hard coding can work.
What would be a better architecture/project to be used to achieve the same?
Database = PostgreSQL.
https://www.postgresql.org/docs/current/sql-notify.html
Appears difficult to implement since there is no ease of usage for so many conditions.
You only have three options:
Poll the database for changes (which as you say, gets expensive).
Check all the rules as the changes are made.
Make a note of changed data as changes are made and check that changed subset in batches.
Whether you prefer #2 or #3 depends on how many rules there are, how long it takes to check them for each changed row and whether you can usefully summarise changes or merge alerts.
Both #2 and #3 would use one or more triggers. Option #2 would run the rules and add entries to an "alerts" queueing table (or NOTIFY a listening process to send an alert, or set a flag in memcached/redis etc).
Option #3 would just note either the IDs of changed rows, or perhaps the details of the change and you would have another process read the changes and generate alerts. This gives you the opportunity to notice that the same change was made twice and only send 1 alert or similar if that is useful to you.
How can I update a particular node that all users have in their own branch?
I am trying to update a users set of points back to 15 after a certain amount of days by a push of a button. I know how to update 1 users node but can't seem to figure out how to do create a function that when I push a button it resets all users that have that branch/var back to 15.
Otherwise, I would have to do it individually which is obviously not efficient.
This is my code to reset 1 of the student's node by a click of a button
Database.database().reference().root.child("students").child(userId).updateChildValues(["points": self.newPoints])
How do I write a method to reset all students who have the value "points" key by a press of a button?
Any help would be appreciated.
Thanks
You can't use wildcards to replace userId and therefore apply it to every node. You would probably need to fetch the entire students node, and update them one by one using a for loop, which would be very inefficient.
You probably want to use a different data structure in your database that would be more appropriate to your situation. Thats said, if you still want to stick with your current structure you can try having your client update a single boolean flag in your database, and then program a trigger function in node.js so that the update is handled on the server side directly. Check out : Firebase Cloud Functions
Central to a project I'm working on is a highlighting-mechanic that can be applied to certain items on the website. The idea is, that this highlighted-status is only active for a certain amount of time.
I'm trying to find the most performant way to achieve this (in querying, setting status, checking status and revoking it)
A first approach would be to set simply set a value 'highlighted:true' to the item. This seems to be the most performant way to query for highlighted items. The Drawback I see here, is that there also needs to be stored a date for the highlighting-action, but furthermore there needs to run an interval to check on the highlighted items and potentially revoke their highlighted status. Also the exact moment when the item stops beeing highlighted can't be determined exactly, since its depending on the interval of the check-function.
A second approach would be to mainly store the date of the highlighting-action and run the query against it. It seems that the query of highlighted objects is way less performant, since every item ever is beeing checked, and on top its not just a boolean, but a proper function that throws those differnt date-values around to check if it is still valid. On the upside there is no external cleanup-function neccessary and every highlighting period ends perfectly on time.
Would love to have your input on this. Is there maybe a clever pattern on this?
I have a collection with a bunch of documents representing various items. Once in a while, I need to update item properties, but the update takes some time. When properties are updated, the item gets a new timestamp for when it was modified. If I run updates one at a time, then there is no problem. However, if I want to run multiple update processes simultaneously, it's possible that one process starts updating the item, but the next process still sees the item as needing an update and starts updating it as well.
One solution is to mark the item as soon as it is retrieved for update (findAndModify), but it seems wasteful to add a whole extra field to every document just to keep track of items currently being updated.
This should be a very common issue. Maybe there are some built-in functions that exist to address it? If not, is there a standard established method to deal with it?
I apologize if this has been addressed before, but I am having a hard time finding this information. I may just be using the wrong terms.
You could use db.currentOp() to check if an update is already in flight.
I keep seeing questions floating through that make reference to a column in a database table named something like DateLastUpdated. I don't get it.
The only companion field I've ever seen is LastUpdateUserId or such. There's never an indicator about why the update took place; or even what the update was.
On top of that, this field is sometimes written from within a trigger, where even less context is available.
It certainly doesn't even come close to being an audit trail; so that can't be the justification. And if there is and audit trail somewhere in a log or whatever, this field would be redundant.
What am I missing? Why is this pattern so popular?
Such a field can be used to detect whether there are conflicting edits made by different processes. When you retrieve a record from the database, you get the previous DateLastUpdated field. After making changes to other fields, you submit the record back to the database layer. The database layer checks that the DateLastUpdated you submit matches the one still in the database. If it matches, then the update is performed (and DateLastUpdated is updated to the current time). However, if it does not match, then some other process has changed the record in the meantime and the current update can be aborted.
It depends on the exact circumstance, but a timestamp like that can be very useful for autogenerated data - you can figure out if something needs to be recalculated if a depedency has changed later on (this is how build systems calculate which files need to be recompiled).
Also, many websites will have data marking "Last changed" on a page, particularly news sites that may edit content. The exact reason isn't necessary (and there likely exist backups in case an audit trail is really necessary), but this data needs to be visible to the end user.
These sorts of things are typically used for business applications where user action is required to initiate the update. Typically, there will be some kind of business app (eg a CRM desktop application) and for most updates there tends to be only one way of making the update.
If you're looking at address data, that was done through the "Maintain Address" screen, etc.
Such database auditing is there to augment business-level auditing, not to replace it. Call centres will sometimes (or always in the case of financial services providers in Australia, as one example) record phone calls. That's part of the audit trail too but doesn't tend to be part of the IT solution as far as the desktop application (and related infrastructure) goes, although that is by no means a hard and fast rule.
Call centre staff will also typically have some sort of "Notes" or "Log" functionality where they can type freeform text as to why the customer called and what action was taken so the next operator can pick up where they left off when the customer rings back.
Triggers will often be used to record exactly what was changed (eg writing the old record to an audit table). The purpose of all this is that with all the information (the notes, recorded call, database audit trail and logs) the previous state of the data can be reconstructed as can the resulting action. This may be to find/resolve bugs in the system or simply as a conflict resolution process with the customer.
It is certainly popular - rails for example has a shorthand for it, as well as a creation timestamp (:timestamps).
At the application level it's very useful, as the same pattern is very common in views - look at the questions here for example (answered 56 secs ago, etc).
It can also be used retrospectively in reporting to generate stats (e.g. what is the growth curve of the number of records in the DB).
there are a couple of scenarios
Let's say you have an address table for your customers
you have your CRM app, the customer calls that his address has changed a month ago, with the LastUpdate column you can see that this row for this customer hasn't been touched in 4 months
usually you use triggers to populate a history table so that you can see all the other history, if you see that the creationdate and updated date are the same there is no point hitting the history table since you won't find anything
you calculate indexes (stock market), you can easily see that it was recalculated just by looking at this column
there are 2 DB servers, by comparing the date column you can find out if all the changes have been replicated or not etc etc ect
This is also very useful if you have to send feeds out to clients that are delta feeds, that is only the records that have been changed or inserted since the data of the last feed are sent.