Search
NoSQL
Persisting Relations Across Time and Space
Edit
#data-persistence
#database
#postgresql
#nosql
#mongodb
#ruby
#object-relational-mapping-orm
Summarized using AI

Persisting Relations Across Time and Space

Piotr Szotkowski • September 29, 2011 • New Orleans, Louisiana • Talk

In the presentation titled "Persisting Relations Across Time and Space," Piotr Szotkowski explores the challenges of persisting objects and their relationships within Ruby applications. He discusses various approaches to entity-relation modeling and persistence techniques, highlighting the evolution from traditional relational databases to more flexible data storage solutions like NoSQL and graph databases.

Key Points:
- Introduction to Persistence: Szotkowski introduces the concept of persistence in Ruby applications, whether for web apps or command-line utilities, emphasizing the need to store objects and relationships.
- Database Challenges: He addresses the complexities of using relational databases (RDBMS), such as MySQL and PostgreSQL, and how they often struggle with effectively modeling relationships between objects.
- NoSQL Databases: The talk covers the rise of NoSQL databases, including document-oriented databases like MongoDB and how they allow for more flexible, schema-less data modeling. He notes the benefits of using embedded documents and the ability to handle arrays and hashes conveniently.
- In-memory and Graph Databases: Szotkowski introduces in-memory options like Redis and emphasizes the effectiveness of graph databases for modeling relationships, particularly useful in social network contexts.
- Utilizing Ruby Libraries: He discusses various Ruby libraries, such as Active Record, PStore, Candy, and Ambition, that facilitate the persistence of data in Ruby applications, with specific examples of transparent persistence in Candy and query abstraction in Ambition.
- Modeling Relationships: The presentation dives into how relationships can be modeled, discussing object-oriented approaches that can abstract persistence from business logic, which allows for greater flexibility and easier testing.
- Future and Conclusions: Szotkowski concludes with reflections on the potential for object databases in Ruby and urges the community to rethink traditional persistence models, advocating for a more abstract approach to dealing with data. He encourages exploration of different persistence strategies, including being mindful about schema development.

Overall, the talk encourages Ruby developers to consider new paradigms for persistence while recognizing the limitations of conventional methods, thereby enhancing the efficiency and performance of their applications.

Persisting Relations Across Time and Space
Piotr Szotkowski • New Orleans, Louisiana • Talk

Date: September 29, 2011
Published: December 12, 2011
Announced: unknown

Entities and their relations are the backbone of many Ruby applications -- from trivial, one-off commandline utilities to full-blown social network websites. The good old relational databases, while showing extreme abilities in both adaptation and survival, are no longer the obvious choice for persistence -- and sometimes obviously not an ideal one. This talk discusses various entity/relation modelling approaches and different persistence techniques -- from rigid schemas in suits to collections of hippie free-form documents; from good old (transactional!) PStore through join-table-happy RDBMSes and muscle-flexing NoSQL hools to (social!) graph databases, waiting patiently for broader recognition and prime time. Quite a few interesting Ruby libraries for gluing all this together are also pondered upon -- from world-class champions like Active Record or ARel to less known gems like Candy and Ambition.

RubyConf 2011

00:00:16.960 i'm very happy to to be here with you and i want to talk about persisting relations across
00:00:22.720 time and space about how we can persist objects and the relations between them
00:00:28.560 in our ruby applications or ruby systems so um
00:00:33.600 a quick introduction my name is uh piotr shotkovsky and if you think that's hard to pronounce i also have a nickname that
00:00:40.239 i have no clue how to pronounce because i ever saw it in print and i'm an alumnus of mendicant university
00:00:47.360 this is where i shaped up my ruby skills and thank you
00:00:53.920 apparently most of you know what mendicant university is it's a wonderful endeavor created by gregory brown and
00:01:00.480 now staffed with quite a few more people who are somewhere there and i will go back to
00:01:07.600 the nearest mendicant university activities at the end of the talk
00:01:12.880 and i'm also a ruby developer uh i work at a new company in warsaw poland we're
00:01:18.479 so fresh we don't have a logo yet so i shamelessly stole stolen the this one from the git community book we
00:01:24.640 were called rebased and i'm also an assistant professor at warsaw university of technology i work at the institute of
00:01:30.799 telecommunications and this is where i try to sneak ruby into the old world of
00:01:36.240 20th century academia basically and that's where i learned ruby when working on my phd and when i decided that it's
00:01:43.520 a very nice language and there's a lot of paradigms that you can
00:01:49.520 use in ruby that are very well used to be
00:01:56.000 they are very convenient to use in the academic world so what this talk is going to be about
00:02:01.680 well you can try asking yourself what can i mean by resisting relations time space what can
00:02:08.319 i possibly mean by all those things so persistence is what we need
00:02:13.760 for our ruby objects because whether we have a web application that people come back to or and hit with separate
00:02:20.560 requests or whether it's a common line utility for doing some stuff we almost always need
00:02:26.160 to persist some of the objects that we have and relations are the tricky things to model because they are usually
00:02:32.000 heavily tied to the persistence whether it's a database or some other sort of persistence that we use
00:02:38.400 the way we model relations are very heavily tied to this and by spaces i mean different ways of
00:02:46.239 persistence but eventually what we want for our ruby objects is basically time travel and
00:02:53.360 unfortunately we only know how to make them travel in time and forward but maybe eventually
00:02:58.800 we also be able to do the reverse and we can somewhat cheat on that by versioning
00:03:04.720 so where do we persist what do you use for persistence
00:03:10.159 database very good so what do we know about databases a database is a black hole into which
00:03:16.640 you put your data if you're lucky you'll get it back again if you're very lucky you'll get it back in a form you can use that's one problem with databases they
00:03:22.879 are not the ruby systems we like to play with they are not the ruby systems we live and breathe they are that other
00:03:29.680 thing that we communicate with and the other thing is that it's some
00:03:35.440 very often it's hard to to to model things right i should like to find a person who decided that since bookmarks and history were both lists of urls they
00:03:42.239 ought to be integrated into a single database i should like to shake him only by the throat until his head comes off
00:03:47.519 this is a quote from roger burton west uh about how firefox stores the bookmarks and history and if you don't
00:03:53.200 know the hate software mailing list i highly recommend it this is the perfect place to be in and and to to take part
00:04:00.239 of if you're a software developer so where do we persist what do we use for
00:04:06.000 the database like the most obvious choice
00:04:11.040 okay there's still hope but usually the answer is mysql and what do we know about mysql uh
00:04:17.759 that's the first half of the quote from well jessup the second half is
00:04:23.280 much less fortunate for mysql so i left it out um but uh
00:04:28.720 this is another thing that i very strongly relate to about mysql because i started my work
00:04:36.160 as a localization engineer and uh yeah but
00:04:42.960 really all the differences between relational databases they are
00:04:48.080 somewhat disputable mysql does have wonderful engines you can have in-memory storage you can have
00:04:54.240 one of the back ends that there's not respect for in keys which is wonderful because it can be faster
00:05:00.479 although if you don't know that it doesn't respect the foreign keys it's kind of not that good but you know
00:05:06.160 there are other other relational databases so like mysql postgresql
00:05:11.520 sqlite which we learned to use for our testing because it's so much faster there's actually an embedded version of
00:05:16.800 sqlite so you don't even have to have sqlite on your system there is a uh so
00:05:22.560 those sites will be or actually are online so all the links will be clickable but there is an embedded sql
00:05:28.560 that you can use in a pure ruby system and basically when we want to persist ruby objects we serialize the properties
00:05:34.320 to database types so we need to figure out how to represent them strings numbers integers flows are easy it comes
00:05:40.960 a bit harder when you have geographic locations but there are relational databases like postgresql
00:05:47.440 which does have geometric types it has points you can say find me all the contacts that are in the vicinity of
00:05:53.600 this given point and if you store the points as a point type rather than floats for example postgresql can do the
00:06:00.560 work for you there are array types in postgresql you if you have posts in your web blog which is i think the generic
00:06:06.800 example and you tag them you not necessarily need to have in postgresql a separate
00:06:12.000 join table for joining posts and tags you can have a tags column it can store arrays of tags and you can ask
00:06:18.160 postgresql please give me all the post targets ruby and persistence or all the post tags ruby or small talk you can do
00:06:25.280 that only having by tags column and having postgres arrays in it there are a lot of things in postgresql types you
00:06:31.280 can have your own types in postgresql it's very worth learning what you can do
00:06:36.560 with postgresql but basically we model our classes as tables we model our objects as rows in those tables and the
00:06:43.120 properties as columns so basically this is not
00:06:48.800 always the ideal solution so the world came up with the very broad thermal no no sql which doesn't mean
00:06:55.360 anything really but the one of my favorite quotes about database is that database research has produced a
00:07:01.599 number of good results but the relational database is not one of them of course it's tongue-in-cheek and it's very
00:07:06.960 uh very i don't know more funny than then probably
00:07:13.759 very true but this is something that people came up with once they
00:07:19.440 learned about all the downsides of operational databases and i absolutely
00:07:24.720 love this opinion about supporting sql language to nosql databases this is not
00:07:31.199 necessarily the best thing to do so but no sql is a very broad term and
00:07:36.639 if we try to narrow it first to document databases like code db or mongodb and
00:07:41.919 again there's an embedded version of mongodb if you didn't know this this is a very interesting idea you can have a pure
00:07:48.080 ruby mongodb without having the actual server for testing
00:07:53.440 for example if you want to have a production like system for testing without setting up the mongodb server
00:07:58.800 and we basically again we serialize properties to database types we can have arrays which are somewhat better
00:08:04.479 supported we have we can have hashes especially in mongodb i think hdb does the same which is very convenient we can
00:08:10.639 have nested documents in i think most of the document databases so there are
00:08:16.639 a bit better ways to persist objects and we but still we basically we say that
00:08:22.080 our classes our collections our objects our documents in those these collections and the properties are basically fields
00:08:29.039 in those documents the good thing is that more often than not we can go with a schema less
00:08:34.479 schema-less approaches which can be very useful quite often
00:08:40.560 how do we persist elsewhere well uh in a memory if we use reddish which is
00:08:45.760 in the general opinion an in-memory kind of database but you can actually have a
00:08:50.800 for example and that that's actually in production in poland in one of the bigger companies you can have another
00:08:57.200 ready server that is synchronized with the first one and that reddish server stores everything to disk so you don't get the overhead of
00:09:03.600 persisting redis data on your main production system but still have persisted readies
00:09:10.080 and if you work with redis a lot there's a redis object collection i think
00:09:15.680 which is a very nice way of doing the opposite what we try to do is basically there are classes that
00:09:21.040 represent redis types so if you can contain your
00:09:26.080 uh ruby objects to be types of those to be objects of the ready subject
00:09:31.680 collection classes you have a one-to-one mapping to redis which is very convenient there are graph databases
00:09:36.880 which are really nifty for doing any kind of social graph activities any kind of
00:09:42.720 basically storing relations and i'll get back to this there are directories of services for example if you have
00:09:49.680 imaginary example you have a university department that has all the students and staff and ldap already for auto
00:09:55.440 authorization and authentication purposes then you can use that as your
00:10:00.640 persistence backend and you can model the rest of your system in ldap as well but there are actually other things that
00:10:07.120 are very underrated and can be used especially in your pet projects yaml record is a
00:10:13.600 active record-like library that lets you store things in objects in plain yam files
00:10:20.399 which is kind of very useful especially if you do a lot of hectic development and you really need
00:10:26.000 to look at the data very quick quickly and pstore pistor is persistent store and is
00:10:31.600 i think my favorite uh standard ruby library that is really
00:10:36.640 underrated it's a it's in the standard library you already have p store in your systems wherever
00:10:42.320 you have ruby it has two back ends you can it can either marshal the objects or
00:10:47.760 put them in the yaml files and all you need to do is either require pstore or require yaml store and then create a
00:10:53.760 store object with the name of the file and if you thought about a very hypothetical
00:10:59.839 example of somebody who for some reason likes to collect quotes and maybe wants
00:11:05.839 to have a command-line utility that would paste those quotes at the end of the image i'm really going very crazy at
00:11:10.959 this moment but just think about it and maybe that person you know had some free time at
00:11:16.160 his honeymoon and created that application and uh um you could do something like this
00:11:22.720 uh just by using the code on this slide you basically create a quotes track which is
00:11:28.800 an author and a text fields you open a read write transaction to the
00:11:34.880 pstore object and then you access it like a hash so we want to store two
00:11:40.320 quotes and databases so we create a key data db key if it's not there and we put
00:11:46.240 the two quotes and at the moment we close this block this is atomically
00:11:51.440 committed to the file so it's a very simple but very powerful obviously you have to have right access to the file
00:11:58.079 system which nowadays is somewhat less popular than it used to be but uh this is this is actually
00:12:04.560 very easy and if you want to read from the pstore store you can have read-only transactions which can be concurrent
00:12:10.639 they only open the file for reading which is fast and if we wanted to print the two quotes
00:12:16.240 that we put in we would just do something like this we would access the the store just like a hash with a dbt
00:12:22.320 and for each quote we would print out the text the two dashes and the author and the an empty line and if we wanted
00:12:28.800 to run this we would print out the two quotes that we stored just a second before and if we
00:12:34.880 try to look at the database it's just the yaml file so it's very easy if for example you spot typos in your quote
00:12:40.399 that that imaginary person if they spotted the typos in the quotes then they could just edit the file rather
00:12:45.519 than trying to figure out how to add editing ability to his solution
00:12:50.959 so basically uh p star is this very old but very useful very underrated solution for persisting
00:12:57.920 your objects you probably should try to use it in your next project so the problem with relations
00:13:04.560 uh the problem with relations and and persisting them is that it's usually very strongly tied to the way you
00:13:09.760 persist things if we have a kind of set of objects we have two parental units at the top you have a we have a kid at the
00:13:16.000 bottom the kid learns geography and writing uh the one of the parental units works
00:13:22.240 at wall street the other parental unit stays at home and does interesting things with the toys he has at home and
00:13:28.639 he also goes to conferences to watch these are slides well that's how this
00:13:34.240 could be when it comes to relations you have the parental relations you have the wall street mom the stay-at-home
00:13:39.600 executive he goes to the conferences the the problem is that all those
00:13:44.720 relations are usually the gist of your system more often than not they are at least a
00:13:50.240 very important part and there's the way that you model them is
00:13:55.279 also really important some of them have additional fields like the date of disposal relationship started the the
00:14:02.959 role at which the person participates at the conference and so on
00:14:08.160 so how do we do that in a relational database you would think a relational database really is all about relations
00:14:14.000 but it's not really it's about the so the name relational in the relational database is about the relations between
00:14:19.680 rows and it says that rows in a single table should have about the same things in the same columns and not really about
00:14:27.600 uh relations between rows and different tables which is what we talked about here if we have one to many relations we
00:14:33.680 use foreign keys if you have many too many relations we have we use a very different way of joining this by using
00:14:40.639 joint tables and the referencing of the relations if we want to find the parents of the kid
00:14:46.639 we need to to join queries through using the either the joint tables or
00:14:51.760 these different keys if these are one-to-many relations so in document databases it's quite
00:14:58.240 different we can use either embedded documents the the canonical example is if you have a post and you have comments
00:15:03.760 they are so highly so tightly related to the post you very seldom on the comments
00:15:08.959 uh without the post that you can embed the comments in the post and then get the post with the comments as a single
00:15:15.600 object from the database and otherwise you use document identify references you basically say
00:15:21.360 well the author of this post is in the people collections under id74
00:15:27.120 and in mongodb you actually have implicit dbrefs if you create a hash that has dollar ref key with the name of
00:15:33.920 a collection and dollar id key with the object id this can be dereferenced either by your driver you can basically
00:15:40.560 say this is the way uh throwing keys in a way are stored and
00:15:46.639 you can dereference it very easily but it's always costly we usually do
00:15:52.160 this on the client side if we want to do it on the server side we need to write functions that do
00:15:57.360 that and there's actually a hydrator which is somewhat different way to to approach
00:16:02.639 this but you might want to take a look at this if you haven't heard about this but the referencing
00:16:08.399 either you do it client-side which means subsequent hits to the database or you do it server-side and you need to kind
00:16:14.079 of program it to do the referencing rather than having a simple join statements that are
00:16:19.199 well-known how are we modeling creations elsewhere in key value stores
00:16:24.240 i think there isn't a very standard way it very depends on how you model your objects and your
00:16:30.639 properties there so you have to explicitly figure out how to model them and graph databases this is really cool
00:16:35.759 in graph databases the whole point of graph database is relations you have vertices that show the objects and i
00:16:41.680 will show you this in a second and the relations are basically the edges on the graph and if the graph has freely labeled
00:16:49.040 edges and vertices you can store all the data about the relation on the edge all the data about
00:16:54.399 the objects in the nodes and this is in the vertices and this is very convenient and
00:17:00.240 you can do all kinds of graph traversal things you can do all kinds of proximity metrics if you want to find
00:17:05.679 all the people in that other social network that i have three shakes of hands to the then the graph database is
00:17:12.240 a really uh good way to store it and there's a picture about graph databases that i assume shamelessly stolen from wikipedia
00:17:18.559 which basically shows you that you have those vertices with people and one with a group
00:17:25.520 and the membership relationships and friendship let's say relationships or
00:17:31.919 knowing between the two people are modeled as edges and this is uh very similar to what i showed you before so
00:17:38.720 graph database are really very again i think still underrated ways to store
00:17:44.880 things and i'm pretty sure they are already quite big at all the social applications say and will be even more
00:17:50.960 big as the times come but what if we modeled relations just
00:17:56.400 like objects like all the other objects in our system we would then have a relations table or collection and if we
00:18:03.200 had a schema less database that could be very flexible we could have all the relations in our system in one big table
00:18:08.720 or in one big collection and the the drawback is that the referencing could be two-step you basically would
00:18:14.960 have to say i want this object i then need to fetch all of its relations relations and then all the other ends of
00:18:22.000 those relations but the the flip side you have all a lot of easily aggregable
00:18:27.360 data you have all this one huge collection of relations that you can mine for whatever kinds of relations
00:18:33.280 there are in your system which so so it has uh good size and bad size obviously
00:18:38.640 but uh i think it's an interesting idea so basically you would have
00:18:44.480 all this a collection of let's say people a collection of hobbies of conferences of
00:18:50.240 workplaces things you study and then this humongous collection of relations between them
00:18:57.200 and just a quick tangent here when you create a table that is named
00:19:02.559 users um if they are really users of your system that's probably right but maybe
00:19:09.919 you know naming can be a bit more improved on and the other quote i really like is calling the table people not
00:19:14.960 users a small blow in support of humanity it's a bit like the recent opinions about human resources calling
00:19:21.919 humans resources obviously and the other thing that i really would love you to all to read there is a great article
00:19:29.360 personal names around the world on the w3c org website and if you
00:19:35.440 create in your next system a people table that has first name and last name
00:19:41.360 please please please have a very good reason because first name and last name is probably the worst thing you can do if
00:19:47.840 you want to track people's names in anything else than a western
00:19:53.840 anglo-saxon reality because even in hungary they actually flipped the first name and the
00:19:59.280 last name and uh you know in in uh iceland iceland in in iceland they
00:20:06.960 have a very different meaning for the first name and last name do read this it's a very well
00:20:12.480 very well very well worth reading piece so again if we had relations as objects what we
00:20:19.039 could do is model everything the same so we could if we if we had a very good abstraction of how we persist things
00:20:26.240 then we could actually change the persistence layers very easily because as long as soon as we don't have
00:20:31.360 relations as foreign keys it's very easy to switch relational data well very easy from academic totally you know detached
00:20:38.240 from the reality point of view but in theory very easy to to switch your backend systems and basically everything
00:20:44.880 is the same everything is an object that you can track one way or the other and persist it
00:20:51.120 so the last big thing that i want to talk about is uh obviously a set of small talk quotes
00:20:58.880 uh 95 of what i know about small.com from the quotes of that guy so my
00:21:04.400 favorite is object-oriented programming to me means only messaging local retention and protection and hiding of state process and extreme light binding
00:21:11.120 of all things it can be done in smaller than lisp there are possibly other systems which is possible but i'm not aware of them so from alan k which you
00:21:18.000 all probably know who is but the answer to to this quote and i'm not sure whether
00:21:24.080 it was a conscious answer or not is that i always thought small talk would be java i just didn't know it would be called ruby when it did from kendall
00:21:30.240 back which is i think my favorite quote about ruby in general but two other quotes are
00:21:36.400 that rubies like smalltalk and pearl had a child with the answer i'd like to say that ruby is the love child of small gonna
00:21:41.760 lisp raised by pearl the eccentric nanny which if you know ruby well enough and if you know other languages is very very
00:21:48.640 true and to the point and the last thing that we all i think
00:21:54.559 think about small talk programmers that they're very kind of high on the abstraction so small dog
00:22:01.679 programmers do not type they lean their heads towards the monitors and meditate the more advanced programmers do not even need monitors and this is something
00:22:08.720 that i think we in the ruby community like to think of ourselves that we have all those short methods six line methods
00:22:14.000 and all those beautiful systems and you know all those cloud services that we can use and uh
00:22:20.559 so so small talk and and ruby i think are very similar in a way that that makes it's a big benefit for ruby so
00:22:28.880 where that why am i bringing a small dock in in a persistent stock well basically
00:22:34.480 because small dog had this wonderful thing of gemstone which is an object database for small dock and
00:22:39.520 it's a way to persist objects and share them between processes that is totally transparent from the point of view of
00:22:44.720 your system you basically have objects and they're there without any explicit safes
00:22:50.080 reads and so on and it's also the company behind maglev and maglev is a ruby implementation with
00:22:55.120 integrated object persistence so they what they're trying to do is bring gemstone to ruby
00:23:00.640 it will be a proprietary system which is not necessarily making me very happy but at least when they're finished which
00:23:07.360 hopefully they will eventually it's a way for us to have object person sense
00:23:14.799 all right yeah so perfect there will be an october when they will
00:23:21.039 release this so hopefully soon enough so now that people are considering nosql more people consider
00:23:27.360 no databases a recent quote from martin folder so what about ruby object databases and this is the kind of
00:23:34.799 part one i'm really happy that in october we'll have a uh object persistence
00:23:40.559 there were other solutions madeleine which to the best of my knowledge died in 2006 odb same hybrid db which
00:23:48.159 actually models objects as a way somewhat like hashes which is a very
00:23:53.520 javascript like way of modeling objects and they they persisted the hashes in a
00:23:58.720 very universal way that would be independent of whether it's a relational database a
00:24:05.840 document database and so on so hybrid db i hope it will be revived but so far it
00:24:10.960 looks like it won't be qb hall i think this is how it's pronounced it's a martial link on sdbm
00:24:16.720 sdbm is a very typical unix tool for persisting things and a simple database
00:24:22.640 management system so kobe hall does this by marshalling objects and putting that in sdbm
00:24:29.039 worth checking out and the last one is ruby object database rod
00:24:34.159 which is not there yet it's heavily developed by a polish developer who does a lot of
00:24:40.880 text analyzes and he has humongous text corporate he can't pull into the memory
00:24:46.480 all at once so he figure out creating his own object database is the way to go he he
00:24:52.480 hopes to have something that is production ready near the end of the year so this is something also worth
00:24:57.679 checking out but basically the problem is i think object databases
00:25:02.880 will be somewhere there in the future for us are not there yet i really do hope they will be there because they
00:25:09.120 would be really really useful so the last thing i want to the the really last thing i want to talk
00:25:15.120 about is how do we actually persist things we have this ruby system and we have those ruby objects in it and then
00:25:21.520 we have the database and then we have usually the rm somewhere in between it and we use active record or data mapper
00:25:29.520 or mongood or mapper we have this uh wonderful new library of rl which
00:25:35.919 lets us pretend we're not doing sql even though if you look at our queries it's very
00:25:42.000 obvious that they are not you know select where this and that they're much more
00:25:48.080 they're not we're still not there yet when it comes to transparent work on
00:25:53.679 on ruby objects so what i would like to quickly briefly show you is candy and ambition
00:26:00.559 which are two unfortunately dead libraries that maybe are worth reviving
00:26:05.760 which are something that actually sparked the idea for this talk and something that i
00:26:11.760 really uh highly relate to so candy created by steve lay who is
00:26:18.400 known for his science fiction podcasts and also his ruby work he
00:26:23.919 created a way to persist objects in mongodb that is totally transparent from the point of view of the system
00:26:30.559 if we require the candy gem and we created a conference class that
00:26:36.000 includes candy piece the naming is somewhat disputable but this is how well it's
00:26:43.120 his choice so uh instead of inheriting we including which is in my opinion a very good thing to do and
00:26:50.559 the moment we did this is the moment we have completely
00:26:55.760 transparent resistance for our ruby objects because the moment we create a new conference object
00:27:01.919 the candy behind it connects to localhost by default obviously you can configure it but
00:27:09.120 really running all these one two three four five lines connects to the default mongodb location
00:27:16.159 connects or creates a database that is named after your user or candy if it cannot find your user
00:27:22.960 then saves the a new empty document to the conference collection which creates the conference collection if it's not
00:27:28.640 there so really all this as i said five lines is all that it's needed to persist your first object in a
00:27:35.520 mongodb all you need to have is a mongodb running on a default port no configuration whatsoever and the other
00:27:40.799 thing that lies very close to the border of insanity and genius in my opinion is the
00:27:46.480 way that candy handles the the persistence because candy has a very small but very powerful
00:27:52.000 method missing a solution that anytime you call a getter or a setter that is not
00:27:58.240 explicitly defined in your class like let's say location equals
00:28:03.279 this makes uh behind the scenes uh save to your database that sets the
00:28:09.039 location key to the new orleans string and steve the last time i checked which
00:28:14.080 was a year ago and unfortunately there was no development on candy since then actually creates a layer that would do
00:28:19.120 this asynchronously because obviously the the the obvious drawback is anytime you write something to your object
00:28:26.080 there's a database query but you can actually abstract it into a synchronous layer
00:28:31.919 so another thing is that if you save a hash it basically saves the hash into mongodb but you can actually read it
00:28:38.559 right back with events parties thursday i do hope you all know there's a party
00:28:43.760 tonight and it has really the i think best website that i ever saw for a party
00:28:49.279 so um what candy shows us and and this is a very small example there's a much
00:28:55.279 more to candy is that there can be a way to do object persistence that is
00:29:00.960 totally transparent because we basically created a new object set some properties and the moment we read
00:29:07.679 anything there's a database select going to the there's a select query or in this case i
00:29:13.679 don't know i think that mongodb calls them selects as well but um there's a query going to the database
00:29:19.600 and actually the objects are cached as well so there's a lot of overhead is taken care of and a
00:29:26.320 lot of other things are tweakable but this is i think a very interesting idea
00:29:32.159 worth pursuing even if it's not for anything production but although he does use this into production systems the
00:29:38.080 best of my knowledge and the other thing is ambition ambition is a framework that
00:29:44.480 again is dead for quite a couple of years now but it used to abstract querying your persistence or basically
00:29:51.600 databases in a way that is very ruby-like if you use the active record adapter of
00:29:57.679 ambition and you had a person class you basically could say person select
00:30:03.760 and then have a typical ruby block that would access the person's properties
00:30:09.039 and behind the scenes ambition would turn this into this query and again it was quite a couple of years ago so you
00:30:16.080 know we we all have rl now but again this is an interesting way of
00:30:21.679 doing pure ruby things with an object collection and all the persistence being
00:30:27.200 taken care of and to let you show how in my opinion powerful it is if
00:30:34.559 you switch the active record with active ldap the whole ruby part the whole select
00:30:39.919 part can stay the same but the query is very different this is how you query ldap systems to to get the same thing
00:30:45.279 which means objects that are valid to have fun with
00:30:50.399 in the after parties probably so ambition again hopefully
00:30:55.760 it will be revived because it's a very nifty if you think of all the back ends that you could use you could have a i
00:31:01.120 don't know flaker backhand github backend anything that basically lets you
00:31:06.240 stay in the ruby world while the persistence or data layer being abstracted away
00:31:12.559 the problem is of course these are not really production
00:31:17.840 but i do think that they are worth pursuing there might not
00:31:23.279 be there yet there might be look nice but not really work five 15 minutes into when you try to
00:31:29.919 implement them but there are some things that that we should probably all think about whether we can make our ruby
00:31:36.240 systems a bit more a bit less aware of the persistence behind them so
00:31:42.000 the the main point that i wanted to to to show you is that we really should consider disassociating the models from
00:31:48.320 the databases and uh steve klebnik recently said we need something better persistence and logic are two separate
00:31:53.919 responsibilities that every race app combines in typical race app you have models and they are one-to-one tied to
00:32:01.919 the database and another quote when i open up ray's project and the models there is full of 100 active record
00:32:08.000 classes i shatter model does not equal persistence and this is something that we should really think about because
00:32:15.679 if we can disassociate the models from the database it can potentially have a lot
00:32:21.440 of benefits and be so much more flexible not to mention easier testable and the
00:32:26.720 thing that you should if anything in this talk really sparked your interest you should really listen to
00:32:31.840 object-oriented programming in rails with jim weirich this is a ruby podcast i think to podcasts ago which covers a
00:32:38.880 lot of how it's how better to model your
00:32:45.200 models basically the objects in your system in a way that is not necessarily tied to the persistence and and how to
00:32:52.320 better program in an object-oriented way thusly so
00:32:57.440 just to recap what i wanted to tell you today there are various ways to persist objects and if
00:33:03.840 you really have a small project side project maybe trying out pstore which i really like might be a good choice
00:33:11.360 if you think how you model your relations then maybe you can have a very interesting solution in the end that
00:33:17.919 would if you treat your relations as objects might be very worthwhile if you treat them as relations maybe you should
00:33:25.440 learn about graph databases and how to query them and all the possibilities they they give you
00:33:30.559 learn about the persistence features about your persistence features and think outside your inbox again
00:33:36.640 just to reiterate postgresql has wonderful types that people heavily underuse in my opinion and try to
00:33:43.840 model things everything as integers and strings which is not necessarily the good thing and please do read the
00:33:48.960 personal names around the world before you create your next people table if it's called people in
00:33:54.720 the first place so um first and foremost please do enjoy being
00:34:00.399 engineers this is what we love the most this is what we love playing with do look at candy do look at ambition try
00:34:06.720 to come up with all solutions like this and if you have any questions i'm happy to answer it and you can find me
00:34:13.440 there on the net
00:34:27.440 do
00:34:57.359 you
Piotr Szotkowski
@chastell
Explore all talks recorded at RubyConf 2011
+55