How it differs from the timescaledb gem?

[jonatas]

Hi friends 👋

I created the timescaledb gem and I'm curious to understand what are the differences between the gem and this project. Can someone help me to understand this? Maybe we can join forces and unify the efforts?

[bilby91]

@jonatas Sorry for the late response! We've been really busy lately and we didn't want to throw a random answer :)

To provide some context, we’ve been working with timescale for more than a year on a couple of customer-related projects using Rails. While working on these projects, we had to monkey patch and hack several aspects of ActiveRecord in order to make it work with timescale but we’ve also added certain APIs in order to make the experience feel more like Rails.

This gem is about extracting the work we have done and giving developers a native way to deal with timescale in the context of Rails. Some of the things that we are looking to implement:

• Migration APIs for timescale abstractions
• Easy introspection for timescale metadata
• APIs for ActiveRecord objects so that we can use aggregation features

Right now we are focusing on getting the baseline in place.

Having said all that, we stumbled upon your gem when we started working on it and felt really happy that other people are seeing the same needs as we are.

Do you have something in mind in terms of how joining forces would look like? Joining forces looks attractive to us!

Thanks for reaching out, looking forward to your feedback.

[jonatas]

Very good @bilby91 ! Thanks for the answer and I just saw that @evan-duncan published the https://github.com/grnhse/activerecord-timescaledb-adapter which seems also another wrapper of the same functionalities 😄

I'm more than happy to help to orchestrate our work and maybe we can see what are the directions of everyone and help each other by offering reviews and see what makes sense.

I started the gem as an exercise to show a proof of concept of how to use Timescaledb with Ruby and keep organizing code to reuse in further projects. I think my work was the most theoretical ones and you already have a real case to be using it.

I had a few people sending PRs and improving the actual code and testing and for now, my main work there is on getting a good support for the toolkit. Increasing the possibilities of data analysis inside the DB by providing a lot of scopes that will make all analytics related stuff easy through the acts_as_timevector macro. You can see some docs here.

I'd love to brainstorm some day and maybe invite the folks from Greenhouse to also join us. I really don't mind to move the repo from my namespace to a shared one. It's more a matter of see if we can collaborate, because I see a lot of opportunity to collaborate and build strong and more safe code if we have more eyes in the same code.

[bilby91]

@jonatas Sent you an email to continue this discussion.

Thanks for starting this 🚀