Hi All,
I have built a simple module (firestore.ex) which I’d like to convert to an ecto adapter.
I’m trying to wrap my head around what I need to do to get this project started started but I seem to be having some difficulties wrapping my head around it.
I though I’d be able to use mongodb_ecto as an example and built something that looks like it but I’m having difficulties understanding where to start.
Does anybody have any resources/guides on how I should go about doing this?
I swear that once I understand how it all works, I will write a guide for others like me so that they can get started easier 
1 Like
Hi, @wojtekmach had written such a guide for mysql here that could help get you started
3 Likes
Thank you, @bottlenecked!
The guide which @wojtekmach has definitely helped me.
On top of that one, this article from @PavelTyk has helped immensely.
I did manage to make an adapter for Google Spanner using both guides: https://github.com/dunyakirkali/spanner_ecto
I also made some progress on my firebase adapter: https://github.com/dunyakirkali/firestore_ecto
But I’m still stuck. So basically both guides aim to help for the case when the DB is an SQL like DB. So both guides show u how to implement an ecto adapter by implementing Ecto.Adapters.SQL however in my case, Firestore is a NoSQL DB therefore I’m trying to implement Ecto.Adapter but from the docs it’s not clear to me what I should be returning from the 6 callbacks that I’m suppose to implement.
I’ve tried looking at mongodb_ecto since it’s also a NoSQL DB but there I only see a subset of the callbacks implemented which confuses me.
Would really appreciate if somebody can nudge me in the right direction here
2 Likes
Hi, not to discourage you or anything but as you noticed Ecto is more geared around SQL stores rather than NOSQL stores. This impedance mismatch will necessarily make the abstraction of accessing Firebase through Ecto (and your own lib) very-very leaky as users of this abstraction will need to be very much aware that they’re accessing a NOSQL store- or they’re in for big surprises (like what guarantees should Ecto.Multi offer for non-ACID compliant stores? Should it even work or should it raise instead? What about JOINs? etc.)
My suggestion would be to forgo Ecto completely, and look to Xandra as an example of building a client for a NOSQL store (Cassandra in this case). Of course some more legwork is required for setting up connection pooling by hand for example (instead of leveraging what Ecto has in-place already), but on the other hand you can tailor your API to closely match your target store and thus make very evident to your users what it is that each API call is supposed to do.
Again, all of this is not meant as a discouragement, but as an attempt to direct your creativity towards something less frustrating perhaps. 
1 Like
I think that you’re right.
I’m trying to fit a square key in a circle keyhole when I try to use Ecto with NoSQL.
The only reason I pursued this project was because I saw that they were some Ecto Adapters for NoSQL DB’s so a assumed that it would be a logical thing to do (whilst I internally also had the feeling that conceptually I was on the wrong path).
Thnx for your reply, I’ll look into Xandra
