The foursquare map video shows how the experience with realm is better (and does that well), but it didn't give me any sense of how it's achieving those results. As a developer, I'd love to see an accompanying explanation with details on how the original version works, and how the realm version works.
LOVE this. I've dealt with the pain of multiple CoreData contexts in different threads and ugggh. This was easily the longest part of our Streak app development, as we needed it to be fast, offline, and fully synced. This is definitely a way better API that accomplishes the same thing as CoreData. If its actually faster too, wow, just amazing.<p>One question - CoreData works really well with built in UIViewControllers like TableViewControllers. Any chance you'll be releasing some code that makes wiring up changes in the models to the controls that are displaying that data?
Wow - this looks really great! As someone who has struggled with Core Data in the past, the API looks great and things seem, on the whole, a lot cleaner. Looking forward to giving it a go.<p>EDIT: I just came across the REST API / JSON import section in the documentation - really cool stuff!!
The API approach vs. SQLite, etc. is interesting - particularly that it does not look to have very many moving parts. I'm curious about transactional semantics though. Are they 'always on' or is there API control (still haven't gone through docs completely yet, so I may answer my own question later).
I could do with some clarification on what problem the product solves, and actually, what the product even is. To me this looks like a new DB, and an ORM style interface to interact with it?<p>I like that it is multi-platform, but SQLLite is a pretty mature DB store available on all the major platforms anyway. I get that it is faster... but presumably there are there trade-offs for this speed gain. I would like a better understanding of what they are. Transaction support?<p>(PS: I would also much prefer if your objects can be typed in a way so they are plain, rather than forced inheritance from RLMObject)<p>EDIT: The blog post at <a href="http://realm.io/news/introducing-realm/" rel="nofollow">http://realm.io/news/introducing-realm/</a> answers some of these questions.
In my experience object persistence rarely needs SQL or other "relational additional stuff" underneath. Typically I need to store objects and their mutual relations persisted as if they were just kept in memory. Have often thought about how weird it was that you could not just persist objects "as they are" without additional mappings etc.
I saw a demo of Realm and had a talk with one the developers a couple of weeks ago. As the demo and our talk progressed I found myself nodding more and more excited. As I understand Realm it seems to be based on a very natural and straightforward principle. It can't NOT be efficient...
I can't wait to try this out in a real project!
I was going to say Android already has SQLite built-in, but they do a good job explaining advantages vs that (more object like syntax, more document like vs. table and schema like, better performance, etc.). Good job.
What does this provide that CoreData doesn't? Whatever it is, it needs to be clearly explained on the landing page. Otherwise it's difficult to understand what problem this solves compared to CoreData.
Looks interesting! The Swift examples on the homepage seem to be showing Obj-C code: <a href="http://cl.ly/image/2r250h3a0A1y" rel="nofollow">http://cl.ly/image/2r250h3a0A1y</a>
I would love to share the swift-specific portion of the getting started docs on www.sososwift.com but <a href="http://realm.io/docs/ios/0.80.0/#swift" rel="nofollow">http://realm.io/docs/ios/0.80.0/#swift</a> doesn't navigate directly to that. If there's a link to Swift instructions for realm, I'll post them and you will find them here <a href="http://www.sososwift.com/?a=realm.io" rel="nofollow">http://www.sososwift.com/?a=realm.io</a> Good luck, looks cool!
Sounds interesting. I'll definitely watch for the Android version :)<p>That said, the "insert" benchmark source for SQLite is a bit disingenuous. It makes a new compiled statement every time it inserts - if you're doing 150,000 inserts, you should <i>definitely</i> be reusing that thing. And on Android, greenDAO (probably others) does this automatically for every insert/update. It's not some edge-casey optimization trick, it's <i>normal</i> SQLite use.
Cool idea. I had the same problem with the intro video that others have mentioned. I'm gonna read more when the Android version is out, since this might actually be able to fix a common pain point I have with my apps with data persistence (I'd like to be able to read recently touched questions in my Stack Exchange app even when I don't have internet, which requires a damn complex caching layer).<p>Just a side note: The SO link you have in the footer seems to not have <i>any</i> questions about your actual product in the tag, but about Java realms instead.
This is looking very good and it could lower the pain of developping mobile apps, especially for independent studios. Looking forward to learn more about the details of data syncing.
Well I think everyone agrees it looks like something pretty interesting but I couldn't find anywhere what's the easiest way of migrating from CoreData w/sqlite to Realm?
Not sure if the tradeoff of rebuilding everything would be worth it for the increase in performance.
A big plus for sqlite is that you can use it everywhere. For example, for a REST service instead of return a JSON I just return the sqlite database. Also, I can see the data in the desktop, use it on python, etc.<p>This could work elsewhere too? Be usable in python?
Realm peeps, can you explain this: "The only restriction is that objects can be used only on the thread on which they were created"? Is this same as Core Data limitation or is there more to it?
Looks good. Would really like to see Swift support. Also, the example showing integration with REST services in interesting, seems like you could do more with that.