Finding objects
19 views
Skip to first unread message
Tim Shadel
Jul 24, 2012, 10:19:12 AM7/24/12
to toystor...@googlegroups.com
If I've read the docs correctly, there isn't anything in there about finding an object by anything but id. Is that right? ActiveRecord methods like Model.all are the kind that _didn't_ move to ActiveModel, if I followed the split. So I'm assuming that _finding_ objects (by query or by 'all') is a different concern than loading, setting, saving, and managing the relationships on those objects. So ToyStore is awesome, and I should get an Adapter-specific way of searching for records. Is that the approach to take?
Thanks!
Tim
John Nunemaker
Jul 24, 2012, 11:29:26 AM7/24/12
to toystor...@googlegroups.com
Correct. What I often do is add in other query patterns I need as I need them. ToyStore could work with regular sql type data stores probably, but I've never tried it. It is more geared for querying by a single key.
If you need more than a single key, you are on your own. The great thing is that with most nosql-ish data stores, adding a few queries on top of toystore is very easy.
Tim Shadel
Jul 24, 2012, 12:52:37 PM7/24/12
to toystor...@googlegroups.com
Cool. So for some like "Facebook," you're mostly starting from one very well known id (the user that logs in), and then finding data through relationships as they move around the app. That's the scenario that fits ToyStore pretty well, and that makes sense since a huge swath of apps are actually a lot like that. Thanks!
Any libs or specific query patterns you recommend for scenarios you hit here and there?
--Tim
John Nunemaker
Jul 24, 2012, 2:27:05 PM7/24/12
to toystor...@googlegroups.com
What data store are you wanting to use? What type of app?
If you aren't sure about toystore, it probably isn't for you, but I'm happy to answer more questions if you can provide more details.
Tim Shadel
Jul 27, 2012, 2:40:35 PM7/27/12
to toystor...@googlegroups.com
Oh, I'm just playing with it right now.
I started building something small using the Git adapter, and quickly couldn't find the 3 records my simple program had made with the example code—that's what prompted the first question.
I had explored ActiveModel & Git a couple years ago, but with the number of libgit2 adapters available now that imitate Rugged (incl an ObjC one), I got curious to see if I could build a simple mobile/web app pair that would allow for the models to be versioned, to diverge, and then (with custom code), to merge back again. ToyStore seemed like a super simple model for working with models that allowed me to swap out the store, and provide guidance on how I would do something similar in iOS. Perhaps a pipe dream; I'm just playing. :-)
So, to give you an example of the kind of query I might be looking for:
How would I grab a list of recently active users for my home page?
Based on your earlier comments, I've just taken the Grit repo that I handed to the adapter, and used its API to do the equivalent of `MyModel.all`. I can see the basic separation, then, of query versus model/relationship work. I'm guessing that to handle the question above, I'd create a new model with some property that's a list of Users; say `ApplicationStatus.recentlyActiveUsers` that I could write code to ensure that the list was fewer than 20, and that my app would push a User object into that model when a User's actions qualified them to be in the list, and that my home page would simply locate that well-known model, access the list of users, and then traverse the relationships needed to render the list onto the page (or, I suppose I could create a model that captured only the salient details, and have that data 'duplicated' between the core app models and the recentlyActiveUsers models...). I guess I expect it to be a lot like Mongo (ObjectIDs embedded into some document property that I can use to go lookup an item in this or another collection), but without all the specifics of querying or indexing, etc. That's left to me to tune to my specific kind of data, stored and indexed how I want it to be, while allowing the bulk of my model logic to remain unchanged because it relies mainly on the unchanging assumption that this stuff is in a basic key/value store of some sort.
Seems like it's pretty powerful for a decent subset of what you _don't_ want to change when you are doing optimization work as your app grows, while also flexible enough to handle shifting storage strategies over time. What would change is the non-key-based retrieval code and impl-specific index declarations, etc.
Am I catching on to the philosophy right?
--Tim
I started building something small using the Git adapter, and quickly couldn't find the 3 records my simple program had made with the example code—that's what prompted the first question.
I had explored ActiveModel & Git a couple years ago, but with the number of libgit2 adapters available now that imitate Rugged (incl an ObjC one), I got curious to see if I could build a simple mobile/web app pair that would allow for the models to be versioned, to diverge, and then (with custom code), to merge back again. ToyStore seemed like a super simple model for working with models that allowed me to swap out the store, and provide guidance on how I would do something similar in iOS. Perhaps a pipe dream; I'm just playing. :-)
So, to give you an example of the kind of query I might be looking for:
How would I grab a list of recently active users for my home page?
Based on your earlier comments, I've just taken the Grit repo that I handed to the adapter, and used its API to do the equivalent of `MyModel.all`. I can see the basic separation, then, of query versus model/relationship work. I'm guessing that to handle the question above, I'd create a new model with some property that's a list of Users; say `ApplicationStatus.recentlyActiveUsers` that I could write code to ensure that the list was fewer than 20, and that my app would push a User object into that model when a User's actions qualified them to be in the list, and that my home page would simply locate that well-known model, access the list of users, and then traverse the relationships needed to render the list onto the page (or, I suppose I could create a model that captured only the salient details, and have that data 'duplicated' between the core app models and the recentlyActiveUsers models...). I guess I expect it to be a lot like Mongo (ObjectIDs embedded into some document property that I can use to go lookup an item in this or another collection), but without all the specifics of querying or indexing, etc. That's left to me to tune to my specific kind of data, stored and indexed how I want it to be, while allowing the bulk of my model logic to remain unchanged because it relies mainly on the unchanging assumption that this stuff is in a basic key/value store of some sort.
Seems like it's pretty powerful for a decent subset of what you _don't_ want to change when you are doing optimization work as your app grows, while also flexible enough to handle shifting storage strategies over time. What would change is the non-key-based retrieval code and impl-specific index declarations, etc.
Am I catching on to the philosophy right?
--Tim
Brandon Keepers
Jul 30, 2012, 9:38:50 AM7/30/12
to toystor...@googlegroups.com
It currently uses Grit, but I would love to move it to Rugged or something libgit2 based.
–Brandon
Reply all
Reply to author
Forward
0 new messages