We use couchbase server 2.2.0 in our production application.
In the last couple of month , when we ExecuteGet on a value, we get the previous value instead of the updated one.
Example scenario (all the actions are synchronized):
UserBalance_12345 is 500.
1. ExecuteSet("UserBalance_12345",1000)
2. ExecuteGet("UserBalance_12345"); -> The result is 500 instead of 1000.
This scenario occur very rarely but still happen and make damage to us because people say their balance is not updated immidietly.
How can such a scenario happen in couchbase?
Do you have a solution for this scenario?
A long time ago, I've also expirienced this issue. Sometimes it returned incorrect values. There are also some forum topics about this. But in my case that data wasn't so important and that issue raised very rarely, so I actually don't tried to figure out what causes it. And this issue is related .net sdk, because i.e. in nodejs sdk with js callbacks it never happend to me.
But I have sevral ideas that may help you.
1) Try to add to your ExecuteStore persist parameter:
PersistTo persistTo = PersistTo.One;
var result = _Client.ExecuteStore(StoreMode.Set, key, value, persistTo);
2) If you store user balance in separate key (just like in question) and it's type fits to ulong you can try to use Increment or ExecuteDecrement function instead of ExecuteStore. Increment/decrement functions are usally work better than store and they are atomic.
Related
I know that this feature is not implemented by mongodb. I am thinking what can be best way to achieve that.
Using caching service ? The approach will work but there is one problem, when the query You watch on is too big, like whole collection, You will never have the first before value, because You start caching only when first change appear on watch.
Service started watching.
Received object id 1, no cache for previous change, caching value.
Received object id 1, cache for previous change, can do comparison, caching value
I see another problem here, if I have 2 watchers which could potentially receive information about the same object, this will cause sync problems, as one process may update cache and second will already receive wrong data, hm. I mean the second process could be in a situation that cached previous value is already the same as the one in mongodb change stream.
I was thinking as well about mongodb replicas, but not sure if the problem can be solved with it.
Best,
Igor
Is it possible to set the value of count to zero when the result to which count is applied is null.
SELECT count(status) FROM ( SELECT last("P-status") AS "status" FROM "autogen"."Pl" WHERE ("Platform" = 'Database-plat' AND "P-status" = 'ERROR') AND time >= now() - 1m GROUP BY time(500ms), "Node" fill(0) )
In this case if the inner query returns null (for all the Node), count doesnt give any value , since fill will be ignored. I need the value to be zero, so that if i have to perform any other operation on the returned result, it can be done.
If possible, how can it be done?
I know this is an old question, but as it still is very relevant and I have been struggling with this problem for over a year now, I'd like to answer to this unanswered question with the current status of this issue according to my research:
The Github issues here and here imply that this problem is known since 2016 and not really understood by the contributers as a problem, as there are questionable rationales for the implementation (like "it's not a bug, it's a feature, because ambiguities of multiple series") that can easily be answered with special rules for unique series identification, but there has not been much activity any more despite heavy interest of the user community. Another point is that they have published version 2.x, which relies more on their new querying language (Flux), so it is very likely they have more or less practically abandoned the 1.x branch with InfluxQL (maybe except for QL backwards compatibility in 2.x and some minor updates, not sure).
Meanwhile I updated Grafana several times, but I had to stick with InfluxDB 1.x for a couple of reasons and the Flux support changed at some point (deprecated Flux plugin, but Flux included in standard InfluxDB plugin, but latter doesn't really work), so that Flux in Grafana is basically not working any more for a while now. I hoped for a better handling of the counting problem there, but now I'm out of luck regarding counting anything in InfluxDB reliably. I even tried some tricks with sum() function, fancy grouping and dummy values that I need to resubtract again and whatnot, but it always boiled down to the same conclusion: InfluxDB can do a lot, but counting just doesn't work.
It's very unsatisfying, but there doesn't seem to be a way to achieve the "eager" goal of counting data points without a system of bloated queries, excessive use of strange rules, dummy values and an insecurity that any query might break any time or break if you need to query only a specific time frame (where any dummy value workaround might not work). And regarding the priority given, this might not be fixed in the near future.
I'm hoping someone can suggest a good technique for sorting Gmail threads by date without needing to get details on potentially thousands of threads.
Right now I use threads.list to get a list of threads, and I'm using whatever order they're returned in. That's mostly correct in that it returns threads in reverse chronological order. Except that chronology is apparently determined by the first message in a thread rather than the thread's most recent message.
That's fine for getting new messages at the top of the list but it's not good if someone has a new reply to a thread that started a few days ago. I'd like to put that at the top of the list, since it's a new message. But threads.list leaves it sorted based on the first message.
I thought the answer might be to sort threads based on historyId. That does sort by the most recent message. But it's also affected by any other thread change. If the user updates the labels on a message (by starring it, for example), historyId changes. Then the message sorts to the top even though it's not new.
I could use threads.get to get details of the thread, and do more intelligent sorting based on that. But users might have thousands of threads and I don't want to have to make this call for every one of them.
Does anyone have a better approach? Something I've missed?
I'm not a developer and never used the API before but I just readed the API documentation and it doesn't seem to have the functionality you want.
Anyway, this is what I understood in your question:
You want is organize threads by the latest message in each one.
I thought you could use a combination of users.messages and threads.list. In users.messages you'll have the ThreadID:
threadId string The ID of the thread the message belongs to.
The method would be using the date of user.messages to organize the latest messages from newer to old, then recursively obtain their original threads by threadId and print the threads with threads.list by their latest received message.
With this method you'll avoid recursion in each thread saving resources and time.
I don't know how new messages are affected by labels or starring, you'll have to find out that.
I apologize in advance if my answer isn't correct or missleading.
I am working on an app where users can create posts that uses Amazon DynamoDB. One of the attributes of a post item in the database is postId. I am searching for the best practice to set this value upon creation. So far, I have thought of:
Counting the current items in the DB and then assigning the value as postId = dbcount + 1. I cannot find a count method for DynamoDB using Swift, and the ways I have found (scan & description) are either inefficient or accurate. Also, I thought of the scenario of 2 users posting at the same time.
I could create a UUID with Swift and set the postId to this value.
Upon these 2 options, which route is better? Is there a preferred industry standard? Option 2 seems to be the better choice, but I am not sure. Are there any other potential alternatives? Thank you!
I would definitely stay away from option 1 - as you said the potential for a race condition is too high and it could be expensive to implement too.
A UUID would certain work and is likely to be the least painful. However, there are other options too. An atomic counter would work. A bit more complicated but you could even use a conditional write. But the logic for that would be a pain.
The advantage of the UUID is that you generate it so that it can be used for, as an example, a row of data in a child table.
I'm using the SmartBear SoapUI 5.2.1 free version.
I have a rather large project and hundreds of web services that require testing. The client wants the testers to use this software and they have no technical experience and no experience with this software.
So, I have to write up Test Cases for all of these services. What I'm struggling with is that some values that are in the XML content need to be unique and rather than a random number I want to be able to use a Global Variable (idCounter) and increment it every time the service call is ran.
Does anyone know what the syntax would be to get this to execute?
The random does not work because very well because it is ranged 1-100 so it is possible to end up with the same ID resulting in a failed call. Also, it is not an issue with various testers running this because the id gets mashed with the users ID as well making it unique to the user.
I could not find anything so far in my searches.
Your question does not have sufficient detail to be able to provide a definitive answer.
The approach that you could take is:
Create a test case property, call it maybe identifier.
Create a transfer properties step, which takes the value, increments it by one, and stores it back in the test case property.
In your call, use the new property. Following your comment, the code would look something like this:
<record_identifier>${yyyymmdd}${username}${#TestCase#identifier}</record_identifier>
You can also create a pre-step to reset this property to some known starting value.