At the time of updating the document, I need to change the TTL according to the value of a field.
Does Couchbase support changing TTL once the document is created?
If you're not mutating the document other than resetting the TTL, use touch.
If you're mutating the document as well, use one of the overrides that allows you to also set the TTL on replace and upsert.
Yes, you can update the TTL of an existing document. Use the replace method which accepts doc id and a TTL value
client.replace(key, expiry, value [, persistTo] ,[ replicateTo])
Related
I would like to set rule, if qradar does not find the string in event payload for one week? How can I do it?
I am looking to list of conditions, but I did not find any suitable condition. I have this:
when the event(s) have not been detected by one or more of there log source types for this many seconds
However I think it is not very suitable for me, because I need to work with payload. Could someone help me how to solve this problem?
One approach to resolve this problem is to use reference sets. A concept for this is explained here. You need two rules and a reference set:
Reference Set
Create a reference set and configure the time to live to the duration when the absence should be detected.
Rule 1 (Tracker Rule)
Set up a rule that triggers on the pattern whose absence you want to detect. In your case a string in the payload. Select "Add to a Reference Set" as rule response. Use the reference set from above.
Rule 2 (Watcher Rule)
Create a second rule which triggers on Event Name (or QID) "Reference Data Expiry". Maybe you need a custom event property for the name of the reference set and/or the expired element too. With this CEP you can test for the expiry of the item added from rule 1.
Can someone please tell me how exactly this #Version works for locking? Because I don't see the version field is saved in the Couchbase, but when I retrieve it, this field is populated with some random value.
Should I manually set this value when save? For example, I have a POST and PUT endpoint. if I don't set the version with the existing version number, I will get a DocumentAlready exist error. But for the POST, it is ok the save without setting the version (I guess it will automatically generate the new random value for the new record).
In couchbase, each document has some metadata associated with it, ex:
"cas": 1571854188210290688,
"expiration": 0,
"flags": 0,
"id": "path::3c23b8a1-55ca-4cd9-a3cc-d6641abf1adc",
"type": "json"
This data is usually transparent to you if you are using Couchbase with Spring Data, but you can inject it in a field if you need to. That is exactly what happens with the #Id annotation. You don't need to worry with the #Version unless you want to do some optmistic/pessimistic locking.
So I have done some hunting around online, and have been able to figure out how to use the enum tag in a swagger doc to specify a list of possible values for a field. However, in my current API what I need instead is to have a list of potential fields, each of which has a string value.
To be more precise, I have a POST request that sends JSON in the request body. As part of this request users need to send a single ID field. However, we accept multiple types of ID fields. So the request would look something like this:
{name:"name", product:"product", [FirstIdType, SecondIdType, ThirdIdType]:"ID Value"}
So I need to have the user submit a JSON that has a name, product, and one of FirstIdType, SecondIdType, or ThirdIdType. Technically it is required to have exactly one of those three ID types in the request, but I don't really mind if that isn't possible in the swagger doc. Noting it in the description for the field is fine.
The other constraint is that I can't really change the design at this point. The app has already been built using this design and changing it is out of my hands. Which means that I can't just make an array of ID Types and then choose one of them.
Here is the relevant bit from my swagger doc. The area that needs changed is the ID field. Any thoughts or directions on how to get that to go forward would be really appreciated.
definitions:
request_post:
description: (post) request schema
properties:
name:
type: string
product:
type: string
Id:
type: string
Instead of defining what optional fields can come on the path, you can label the fields that are required and make the rest variable by default.
http://swagger.io/specification/#parameterObject
required boolean Determines whether this parameter is mandatory. If
the parameter is in "path", this property is required and its value
MUST be true. Otherwise, the property MAY be included and its default
value is false.
I am running OpenLDAP 2.4.31. Based on Reverse Group Membership Maintenance:
The memberof overlay updates an attribute (by default memberOf) whenever changes occur to the membership attribute (by default member) of entries of the objectclass (by default groupOfNames) configured to trigger updates.
I would like to change these defaults, so the overlay is based on the objectClass groupOfUniqueNames and the attribute uniqueMember. I did not find any mention on how to do this in the documentation, and also I did not find any default setting for this in cn=config; what are the settings that I have to add here to make the desired changes?
I have already added the memberof and referential integrity configuration to cn=config based on this article.
Use the following to change the memberof behaviour. I'm showing the solution here for a traditional slapd.conf configuration.
memberof-group-oc groupOfUniqueNames
memberof-member-ad uniqueMember
As for the referential integrity, you can use the memberof overlay's own setting to do this, which is much easier:
memberof-refint true
For cn=config, you probably therefore want the following:
olcMemberOfRefInt: TRUE
olcMemberOfGroupOC: groupOfUniqueNames
olcMemberOfMemberAD: UniqueMember
The example provided on www.schenkels.nl (your link) almost gets you there. You can append the following to the block dn: olcOverlay={0}memberof,olcDatabase={1}hdb,cn=config:
olcMemberOfGroupOC: groupOfNames
olcMemberOfMemberAD: member
olcMemberOfMemberOfAD: memberOf
Above shows the defaults that you already mentioned. It should be possible to change those to the attributes you want to use. Check out the member-of man page for a description of the configuration options.
Is it possible to create an index on a Boolean type field?
Lets say the schema of the records I want to store is:
{
id:1,
name:"Kris",
_dirty:true
}
I created normal not unique index (onupgradeneeded):
...
store.createIndex("dirty","_dirty",{ unique: false })
...
The index is created, but it is empty! - In the index IndexedDB browser there are no records with Boolean values - only Strings, Numbers and Dates or even Arrays.
I am using Chrome 25 canary
I would like to find all records that have _dirty attribute set to true - do I have to modify _dirty to string or int then?
Yes, boolean is not a valid key.
If you must, of course you can resolve to 1 and 0.
But it is for good reason. Indexing boolean value is not informative. In your above case, you can do table scan and filter on-the-fly, rather than index query.
The answer marked as checked is not entirely correct.
You cannot create an index on a property that contains values of the Boolean JavaScript type. That part of the other answer is correct. If you have an object like var obj = {isActive: true};, trying to create an index on obj.isActive will not work and the browser will report an error message.
However, you can easily simulate the desired result. indexedDB does not insert properties that are not present in an object into an index. Therefore, you can define a property to represent true, and not define the property to represent false. When the property exists, the object will appear in the index. When the property does not exist, the object will not appear in the index.
Example
For example, suppose you have an object store of 'obj' objects. Suppose you want to create a boolean-like index on the isActive property of these objects.
Start by creating an index on the isActive property. In the onupgradeneeded callback function, use store.createIndex('isActive','isActive');
To represent 'true' for an object, simply use obj.isActive = 1;. Then add or put the object into the object store. When you want to query for all objects where isActive is set, you simply use db.transaction('store').index('isActive').openCursor();.
To represent false, simply use delete obj.isActive; and then add or or put the object into the object store.
When you query for all objects where isActive is set, these objects that are missing the isActive property (because it was deleted or never set) will not appear when iterating with the cursor.
Voila, a boolean index.
Performance notes
Opening a cursor on an index like was done in the example used here will provide good performance. The difference in performance is not noticeable with small data, but it is extremely noticeable when storing a larger amount of objects. There is no need to adopt some third party library to accomplish 'boolean indices'. This is a mundane and simple feature you can do on your own. You should try to use the native functionality as much as possible.
Boolean properties describe the exclusive state (Active/Inactive), 'On/Off', 'Enabled/Disabled', 'Yes/No'. You can use these value pairs instead of Boolean in JS data model for readability. Also this tactic allow to add other states ('NotSet', for situation if something was not configured in object, etc.)...
I've used 0 and 1 instead of boolean type.