Thanks for the details.
I did a little experimenting and it works as advertised. Notes below show
what I did and found.
I was interested to see if this might be suitable as a simple om.next
remote for a relational database. Potentially fanciful but it's a topic of
interest for me at the moment.
I used an existing database so I had a semi interesting dataset to play
with.
Races (Id, RaceNumber, RaceTime, MeetingId, SupervisorId, AnalystId...)
Meetings (Id, MeetingDate, MeetingTypeId, VenueId, JurisdictionId, ...)
Venues (Id, Name)
Jurisdiction (Id, Name, Code)
The table and foreign key naming conventions didn't match so I created
views for each table. If that was configurable then you'd open yourself to
a wider audience. (e.g. MeetingId vs meetings_id)
It was easy to setup some associations
(def associations
{:meeting {:race :has-many
:jurisdiction :belongs-to
:venue :belongs-to}
:race {:meeting :belongs-to
:jurisdiction [:through :meeting :belongs-to]}
:venue {}})
My queries all worked as expected.
(find-one db-state :meeting #{:race} [[:= :meeting.id 5617]])
(find-one db-state :meeting #{:venue} [[:= :meeting.id 5617]])
(find-one db-state :race #{:meeting :jurisdiction} [[:= :race.id 42792]])
I couldn't see how I might pull data which requires three levels of
information (e.g. race -> meeting -> venue). I didn't dig deep enough to
be sure.
Incidentally, in case you haven't come across the datomic pull inspired
om.next remote pull syntax this is what it might look like:
[{:meeting [:race]}]
(find-one db-state :meeting #{:race} [])
[({:meeting [:race]} [:= :meeting.id 5617])]
(find-one db-state :meeting #{:race} [[:= :meeting.id 5617]])
[{:meeting [:venue]}]
(find-one db-state :meeting #{:venue} [[:= :meeting.id 5617]])
[{:race [{:meeting [{:venue :jurisdiction}]}]}]
Not prettier necessarily but allows for composing multiple queries into a
request and for drilling deeper into available data.
cheers, Oliver
On Sunday, 28 February 2016 20:02:15 UTC+11, Krzysiek Herod wrote:
>
> Thanks Oliver for the feedback,
>
> actually I came up with the idea of relational_mapper while working on a
> project in which I had one "data-model" that contained all the database
> related information, but the database related code contained a lot of
> features, and I really like working with small, focused clojure libraries,
> so in the end relational_mapper is as small as I could think of it.
>
> Also as you can see in this commit:
> https://github.com/netizer/relational_mapper/commit/6b4d79f92570bf723e4092d329978d484c01d2ab#diff-2b44df73d826687086fd1972295f8bd0L8
>
> I actually was storing both: relations and fields in the same structure,
> but I changed that because I needed "fields" only for migrations that I
> used in tests, and because the whole structure was unnecessarily complex
> (it was much easier to make mistake modifying the fields/associations
> structure).
>
> Relational Mapper is meant only for reading data because whenever I tried
> to use complex structures to write data, I was unhappy with the result
> (often you have to update indexes of related records after one of them -
> with auto-increment field - is created, and there is a problem of
> determining if the related record has to be created or updated).
>
> I didn't write compare/contrast points because I couldn't find similar
> libraries in clojure. I mentioned ActiveRecord in README mostly because of
> the wording in types of relations, but even ActiveRecord is very far from
> Relational Mapper (it's much bigger, and has features that go way beyond
> simple relational mapping).
>
> Thanks again,
> Krzysiek
>
> On Sunday, February 28, 2016 at 10:54:57 AM UTC+8, Oliver George wrote:
>>
>>
>> Seems pretty nice to me. Like a light weight version of the Django's
>> migrate and queryset features which build on model definitions.
>>
>> It seems like this would allow me to define a database schema (tables,
>> relations and fields) as data and use it to both create the database and
>> run select/insert/update/delete queries against it.
>>
>> Is that your intention for the library?
>>
>> I've not explored the options in this space before. It might be good to
>> have a section in the README pointing out to other related tools with some
>> compare/contrast points.
>>
>> Thanks.
>>
>>
>> On Friday, 26 February 2016 17:51:10 UTC+11, Krzysiek Herod wrote:
>>>
>>> I created Relational Mapper, for situations where there is a relational
>>> database with certain amount of relations between tables and it's just not
>>> cool to fetch data from each table separately nor to write custom code for
>>> each such project so, with this library, you can just call:
>>>
>>> (find_all db-state :posts #{:authors :attachments} [:= post.id 1])
>>>
>>> and assuming you have appropriate relations between these tables, you'll
>>> get:
>>>
>>> {:posts {:title "Christmas"
>>> :body "Merry Christmas!"
>>> :id 1
>>> :authors_id 10
>>> :authors {:name "Rudolf" :id 10}
>>> :attachments [{:name "rudolf.png" :id 100 :posts_id 1}
>>> {:name "santa.png" :id 101 :posts_id 1}]
>>>
>>>
>>> The code is here: https://github.com/netizer/relational_mapper
>>>
>>> Please, guys, let me know what do you think, and if you have any ideas
>>> about improvements. If somebody would be so kind to take a look at the
>>> code, it would be awesome to read some feedback.
>>>
>>> Krzysiek Heród
>>>
>>
--
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.
