Considering the regular use-cases with records: Create - requires record without any auto-generated identifiers Retrieve - requires primary identifier or lookup parameters Update - requires record with primary identifier and updated fields Delete - requires primary identifier or lookup parameters
Retrieve and Delete and quite similar, except that `Retrieve` returns record(s). Create and Update are similar, except that `Update` requires only the updated fields. It is clear that one record type cannot expose all of the CRUD operations. Could it be possible that protocols/records are a wrong axis to think about this problem? Can you share some details about the type of database and the access use cases you are considering? Shantanu On Sunday, 28 August 2016 19:59:46 UTC+5:30, Jonathon McKitrick wrote: > > I'm beginning a foray into protocols after coming from the Common Lisp > world of multimethods. I'm using them initially to implement a consistent > load/save API over the DB layer. > > It's pretty simple to have a Saveable protocol to save one object, because > the first argument is a Record of the type I am saving. > > But since protocols dispatch on the first argument, how do you define a > Loadable protocol that loads an object or handles a collection of objects? > > For example, if I want to load an object by idx, the first argument is not > a Record, but an integer, or perhaps an arbitrary field to used in a query. > > > -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
