Requesting Feedback on new Relational Mapping lib for Clojure
Brenton
I have been working on a relational mapping library for Clojure named
Carte.
http://github.com/brentonashworth/carte
The current version is what I would consider to be a working prototype
and I would love to get feedback from the community before I do much
more work on this. The project includes a rather lengthy README.
Mainly, I am interested in constructive criticism of the ideas and
examples contained in the README but if you would like to jump into
the code and critique that, that would be great.
This is my idea of an idiomatic Clojure relational mapping library. Do
you think I am on the right track? If not, what would that look like?
What would Rich do?
This project is being developing for my own immediate needs but I
would be interested in improving it outside of the scope of my work
based on your feedback.
Thank you,
Brenton
Christophe Grand
It's nice to see someone writing a relational mapper.
I never got farther than pondering on API design but I share my design
thoughts in case it can be useful to you:
* relations (tables/views/joins) would be a reference type (when
dereferenced they would return a seq or set of maps),
* keys would be namespaced (:album/id and :track/id etc.), foreign
keys use the ns of the foreign table
* join would be implicitly on matching key names (thus the importance
of namespacing)
* transactions would be delimted by a (dbsync ...) forms
* the API would try to be as close as possible of clojure.set
hth,
Christophe
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clo...@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+u...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
>
--
European Clojure Training Session: Brussels, 23-25/6 http://conj-labs.eu/
Professional: http://cgrand.net/ (fr)
On Clojure: http://clj-me.cgrand.net/ (en)
Base
James Reeves
> The current version is what I would consider to be a working prototype
> and I would love to get feedback from the community before I do much
> more work on this.
I've been thinking about a similar problem.
Most database mappers have three components:
1. The model instance
2. The model collection
3. The model factory
I've been considering how to represent specific model instances in
Clojure. We probably expect a model instance to:
1. Locally cache its value
2. Be able to save changes on request
3. Be able to refresh itself on request
In Clojure, this might look something like:
user=> @user
Log: Fetching data from database
User{:login "jbloggs"}
user=> @user
User{:login "jbloggs"}
user=> (refresh user)
nil
user=> @user
Log: Fetching data from database
User{:login "jbloggs"}
user=> (update user assoc :name "Joe Bloggs")
User{:login "jbloggs", :name "Joe Bloggs"}
user=> (save user)
Log: Saving data to database
User{:login "jbloggs", :name "Joe Bloggs"}
- James
Jeff Rose
especially if you just skip to the example queries to get a sense for
the library. It would be much clearer to make these something more
meaningful (e.g. lookup, query, update, find, get...)
It seems like your model macro is in fact defining many models. I
wonder if it always makes sense to define all models and relations
(one-to-many, etc..) in one place like this, rather than doing it on a
per "object" basis, for example just for an Album, Track, or
whatever? Beyond that, is it even necessary to put schema information
like :id and :name? If you are defining models that can then be
"instantiated" into a database by actually creating the tables then it
makes sense to have a DSL to define them, but if you are interacting
with an existing schema it might be nice not to have to do this.
The query functionality looks pretty nice and straight forward. If
you use macros for the query functions you could let users use symbol
names rather than keywords, which might make it a bit clearer to read
because you could more easily differentiate between tables, properties
and special words like :with that have semantic meaning.
Good stuff though. I tried to be critical because I know that can be
more helpful than a bunch of high fives. On a related note, you might
be able to get some good ideas from the Sequel library for Ruby
(http://sequel.rubyforge.org/), which has some very nice features that
could fit nicely with Clojure. I have minimal experience with it, but
I think rather than generating SQL and getting back all results
immediately it lazily processes results with SQL iterators as you pull
values.
Cheers,
Jeff
rb
I think it would be nice if rather than specifying the columns of each
table in the call to the model macro, it was extracted from the
database directly.
Raph
Brenton
rb and Jeff
Future versions of Carte will not force you to list the column names
but will retrieve them from the database.
Jeff
The model macro produces a map which may then be merged with other
model maps so you could define the model in various places. That feels
more like an object oriented approach and Carte is not trying to be
object oriented. It seems natural in a more bottom-up style to define
everything in one place.
I like that queries are just data but I also see how they can be a
little hard to read. I am considering using a macro for queries that
would allow table names to be written as symbols instead of keywords.
My main concern is to ensure that queries behave in the same way as
the rest of Clojure.
Thanks again,
Brenton