As part of storing data. Does hazelcast stores metadata information like RIAK?.
If so, whether we can store custom metadata information?.
Thanks in advance
Dinesh
What kind of metadata stores riak and what kind of data do you want to store?
We store some internal metadata like last access timestamp or hits and similar but this probably not what you're asking for. We also do not have user custom metadata depending on what you expect to store. Custom metadata can for sure be stored in another map using the same key.
Related
I build an API, which will send data to another API when has been collect 10 hashes. The client sends 1 hash per hour.
For example:
The client POST hash to API
API need to store it somewhere until the hashes number becomes to 10
When the number of hashes becomes 10 need to send data to another API and start from 0 again
My question related to the 2nd point. I can store the hashes in the array, the problem is that the data will be lost when the server will be shut down suddenly.
This is the only data which I need to store in API, so I don't want to use DBS.
By the way, it's my first time of developing API, so will be glad to your help.
Thanks in advance.
Sorry but your only options of storing data are either memory or disk.
If you store data in variables, you're using memory. It is fast and instant but it's not durable as you already said.
If you store data in database, you're using disk storage. It is slower but it is durable.
If you need durability, then database is your only option. Or maybe if you don't want to store the data in your machine, you could use cloud database such as firebase database.
Maybe your problem will be solved with Redis.
I had one feature where I needed to use some user's pieces of information on the server side in runtime and it could not be persisted at the database.
So, I used this.
In simple words, the redis will save the information in your cache and you can retrieve when you need.
There's no disk use and are more stable than a hand made memory control.
I hope this helps you.
I want to create a database which stores the user data for a temporary period of time (i.e) Until the user logout.
Once the user logged out, I want all the details they are provided to get deleted.
My question is, can we use mongoDB for temporary storage. Until the user logout!
Or is there any other solution for this?
My answer is yes, you can use mongoDB for temporary storage. You can even set a TTL for the document so it will expire after an amount of time.
Here is the link for the documentation: https://docs.mongodb.com/manual/tutorial/expire-data/
Another solution would be to store that kind of information in a database that persists only in memory like Redis. That way you could gain some performance even.
You can use any database to do that. Just delete the data when the user logs out.
Redis may be a good fit for that because it stores the data in RAM, see:
http://redis.io/
But really any database can do it. You will just have to remove the data on logout.
Since you tagged your question with "mean-stack" then I assume that you're using Express. There are some modules that can help you with what you're trying to do. See the Compatible Session Stores in the express-session documentation.
Some of the more relevant modules from that list:
connect-mongo (for Mongo, as you asked)
connect-mongodb-session (another one for Mongo)
connect-redis (for Redis, which is well suited for that use case)
connect-sqlite3 (for SQLite, an embedded RDBMS that you don't have to install)
session-file-store (for storing session data in files)
or you can use the default in-memory session storage for testing (not suitable for production)
I'm using PouchDB + CouchDB to store and sync data in an angular app currently in development. Data is stored per user and contains things such as user authorities/settings, recently viewed content and cart items.
Currently, I have a single CouchDB database that contains a doc for each user. While this structure works well for quickly retrieving user-specific data, it's logically flawed because all user docs are synced to any device that accesses the app. In other words, I ultimately only need the currently logged in user's data to sync.
So, my question is, should I create a Couch database for each user instead of using a single database with a doc for each user? Or is there a better way to go about this?
If you look at the pouchdb-authentication plugin you'll see that you can store metadata for a user in the _user database. That might be all you need.
I'm investigating ServiceStack's Authorization feature and want to use Couchbase as my data store. I understand there isn't an IUserAuthRepository implementation for Couchbase so I'd have to develop my own, which isn't a problem.
The issue I am having is if I store the built-in UserAuth object as-is, CB it uses the Id field as the document identifier. This is a problem because I believe the identifier should be object type specific, otherwise a separate 'bucket' would be required to prevent conflicting id's across different objects. I don't really want to have lots of buckets unless I have to.
My preference would be to have the document id set to the type of the object plus the object specific identifier.
eg Using Id "UserAuth_1234" or using UserName "UserAuth_MikeGoldsmith"
Is my assumption of trying to re-use a bucket for different application objects valid or should I be thinking about a bucket per object-type / namespace?
Any direction would be welcome, both from Couchbase and ServiceStack enthusiasts.
Thanks
Additional Info
Ok, so from John's answer I will assume my additional property for the object type is valid.
I found this post where Mythz suggests the BootStrapApi example extends the AuthUser with custom properties. However, to me it looks like the AuthUser is persisted twice, first as the AuthUser and again as the User object (both times using the OrmLiteAuthRepository). Am I right?
Essentially, I want to utilise the SS auth feature, but control the POCO object that will be saved into Couchbase. Can someone give some direction if this is possible and if so, what I need to implement / hook into?
I tried implementing a Couchbase version of IUserAuthRepository, however it uses the UseAuth concrete type so I can't use my own object.
I also tried hooking into the OnAuthenticated method of AuthUserSession but at this point the UserAuth POCO will have been persisted using the register IUserAuthRepository.
I'm happy to use the CredentialsAuthProvider as I just want username/password authentication. More could be added later.
Thanks again!
Buckets are loosely analogous to databases in the relational world, so generally they shouldn't be mapped to application objects. I'm not familiar with ServiceStack's auth feature, but your suggestion to use meaningful, prefixed keys seems reasonable and is a common approach for providing document taxonomy.
Keep in mind that in Couchbase, there's no field in the document that's considered an "id" or "key" field. The key used to store the document is available in metadata, but is not part of the JSON document itself. So if you're able to take advantage of views, then you could also store a document with a type attribute and then query by some non-id property. In other words, the key in the key value doesn't have to be the way you retrieve the user auth document.
Also, there are developers who use key prefixing as a way to provide document taxonomy for views, so you're key pattern above would work for that too. My preference is a type property, but that's no more valid than your suggestion.
I've come across the ServiceStack UseCase examples, with one that addresses my Custom Authentication issue directy.
I was able to override the TryAuthenticate method and use my own UserRepository that backs onto Couchbase.
I have entities Account and CreditCard in Core Data. An account can have multiple creditCards. Each creditCard has an number. How do I encrypt the number?
I know I could use Keychain Services without Core Data, but could I use them together? The reason I want to use Core Data instead of something like NSUserDefaults is because I want to handle multiple accounts. I haven't used Keychain Services, so I'm not sure if it'd be good for multiple accounts.
You can store your keychain object in Core Data by transforming it into an NSData object. This is not all that trivial, as you need to transform it back and forth correctly. Check out these documentation documents about Non-Standard Persistent Attributes to help you.
You can change the attributes that you want to encrypt to type Transformable, and create your own NSValueTransformer that encrypts when transformedValue is called and decrypts when reverseTransformedValue is called.
Transformable attributes:
https://developer.apple.com/library/prerelease/ios/samplecode/PhotoLocations/Introduction/Intro.html
Example of decrypt/encrypt AES256:
https://gist.github.com/m1entus/f70d4d1465b90d9ee024