I'm using MongoDB w/ Sinatra for an iPhone app.
I have a users MongoDB collection and a picture GridFS collection. Each user has one picture, so, initially, I just set the ObjectId for the picture to be the same as the corresponding user. That made it easy to, given the user's ObjectId, get the picture of that user with just one query. Then, I was planning to store the MD5 hash of the picture in the user object so that the iPhone would know to download the picture only if the MD5 hash had changed. This would work, but I had to modify the Grid Ruby class to get the MD5
But then, Kyle Banker suggested that I just store the picture_id, instead of the MD5, in the user object. But, if I do that, given a user ObjectId, I'd have to first query the picture_id from the user, and then query the picture (2 queries). Is there a way, in one query, to get the picture given a user's ObjectId? Reading up on GridFS indexes, I think there's a way to store the user's ObjectId in the meta data of the picture and then set an index on that field. That way, I could do it in one query. If that's correct, what's the code look like to do that in Ruby?
Alas, should I even bother? I could just as easily use the picture_id to query the picture, which is what I'll do for now, but it'd also be nice, from a syntactical perspective, to be able to query the picture (in one indexed/fast query) by the user_id. Kinda like Facebook's graph api lets you do, e.g., http://graph.facebook.com/mattdipasquale/picture.
Sure. Like you suggest, just store the user_id somewhere in the picture's file object, and build an an index on that field.
Related
I am using a dynamoDB table with GraphQL api to store posts. I want a user to be able to mark certain posts as favorites.
I have thought to create a relation table of user to post, but I also thought to just add an array of userId's to the post object with all the userIds of users who have made that post a favorite.
My understanding is a UUID is 16 bytes so even if say 10,000 users favorite the object then that array will be 160kb. Not insignificant but manageable to pass that much data with the object each time it is loaded.
Just wondering what is the best practice for this scenario. I'm pretty new to nosql.
With dynamoDB you have to think about access patterns first:
To get the favorite posts of a user, store a postsIds array in the user table
To get the users who like a post, store a likerIds array in the post table
To get a bidirectional link, do both of the above
Please also keep in mind that:
You can select fields when getting a document (only select the fields you are interested in)
I don't see a scenario where you would load 10k usernames and display them
The above solution looks pretty good for common scenarios.
More advanced solution:
There could be a more powerful way to do that using range keys. For instance:
Hash Key: postID
range key: likerID
title
...
post1
MyFancyPost
post1
user1
post1
user2
This structures is more powerful, and could store a lot of connections without having any "big" field in the post model.
you could easily paginate, and count the list of likers
can handle many more likers for only one post
I'm playing around with a workout app (android), and want to match workouts to dates. The basic structure is :
Each date has zero or one workouts.
Each workout has one or more exercises.
Each exercise has a name, and one or more sets.
Each set has a weight, and one or more repetitions.
I'm considering a json file, where:
Each date attribute has a list of exercise objects.
Each exercise object has a name, and a list of set objects.
Each set object has a weight attribute and a repetitions attribute.
Thoughts?
If you are doing it with Android, use clases to represent the different entities you have mentioned.
To persist the information inside the phone, I sugest you use the built in sqlite database.
If you plan to build the app as the front end for a rest api or webservice, then yes you can use a json file to exchange informtion with the server. Now, on the server, you would persist the data in a database of your choice. I would go with a relational database like mysql, but for the model you are proposing it would be feasable to also go with a Nosql alternative.
In our application we will give titles to users based on their points. So, if a user has 10-99 points, that user might get the "Novice" title, but a user with 100-199 points might get the "Regular User" title. I plan on eager loading a user's points using an attribute and relationship, and once I have those points I will use an attribute method to assign the title.
But how do I get the list of possible titles?
I could make a model, a migration, and a seed file, but I feel like these titles won't change much and certainly would never need to be updated in an API call. I could also hardcode an array of points and titles and do a quick lookup to see which title belongs to a user, but then I need to somehow deliver those titles to the user in an Attribute method. Or I could store them in a repository or the cache.
Can I access a repository from within a model? Is it better to store this sort of data in a DB anyways, regardless of how often it's updated or queried?
You could use entries in your .env file to store the entries and then use some logic in your php to select the correct .env entry.
LEVEL_1_TITLE=Novice
LEVEL_2_TITLE=Regular
...
if($user->points < 99){
$title = env('LEVEL_1_TITLE');
}
...
Or do the same thing from an array in a class that you create and just select the correct array entry based on the points.
I am trying to wrap my head around Bleve and I understand everything that is going on in the tutorials, videos and documentation. I however get very confused when I am using it on BoltDB and don't know how to start.
Say I have an existing BoltDB database called data.db populated with values of struct type Person
type Person struct {
ID int `json:"id"`
Name string `json:"name"`
Age int `json:"age"`
Sex string `json:"sex"`
}
How do I index this data so that I can do a search? How do I handle the indexing of data that will be stored in the database in the future?
Any help will be highly appreciated.
Bleve uses BoltDB as one of several backend stores and is separate from where you store your application data. To index your data in Bleve, simply add your Index:
index.Index(person.ID, person)
That index exists separately from your application data (whether it's in Bolt, Postgres, etc).
To retrieve your data, you'll need to construct a search request using bleve.NewSearchRequest(), then call Index.Search(). This will return a SearchResult which includes a Hits field where you can retrieve the ID for your object. You can use this to look up the object in your application data store.
Disclaimer: I am the author of BoltDB.
How you index your data depends on how you want to query for it.
If you want to query by any arbitrary fields, like {Age:15, Name:"Bob"} then BoltDB isn't an awesome fit for your problem.
BoltDB is simply a key value store with fast access to sequential keys and efficient prefix seeking. It's not really a replacement for general use databases.
You likely want something more like a document store (ie: MongoDB) or RDBMS (ie: PostgreSQL).
If you just wanted something that uses simple files and is embedded, you could also use SQlite with the Go module
If you want to search by only a single field, like ID or Name, then use that as the key.
If lookup speed doesn't matter at all, I guess you can use Bolt to just iterate over the entire db, parse the json and check the fields. But that's probably the worst approach you could take.
CouchDB's versioning is an absolute boon to the application I'm writing, but each of the objects I want to represent in the database has it's own unique identifier (let's call it my_id), so I don't really need the _id field.
Is there a way for me to tell CouchDB that I want to make my field the primary hey (not _id)?
I'm using ruby's couchrest_model, so I know I can do Model.find_by_my_id(params[:my_id]) if I've put view_by :my_id in my class, but this feels like I'm storing an _id for no purpose. Should I care?
would it not be possible to, when you create the document, provide your own id instead of the default one couchb assigns? I don't know if ruby's couchrest can do it, but it's available in the CouchDB API
See here: http://wiki.apache.org/couchdb/HTTP_Document_API#PUT
The document ID is passed into the url.