Is it time to redefine the purpose of ActiveHash?

[kbrock]

Has the purpose of ActiveHash changed?

Many of the recent feature requests feel like it is going towards an in-memory thread safe transactional database.

README.md [ref]

ActiveHash is a simple base class that allows you to use a ruby hash as a readonly datasource for an ActiveRecord-like model.

I read that ActiveHash is an alternative to storing reference data in the database or in constants.

ActiveHash assumes that every hash has an :id key, which is what you would probably store in a database. This allows you to seamlessly upgrade from ActiveHash objects to full ActiveRecord objects without having to change any code in your app, or any foreign keys in your database.

It even has a suggested migration plan for when requirements change and data is no longer read only. Then it suggests migrating the model to the standard SQL datastore. (or sqlite with ":memory:")

Question

I don't feel that this library and the definition of this library match.

Is it time to re-evaluate the use cases for this library?
Hopefully update the statement at the top of README.md?

[rubydesign]

I know this is old, but since it's open i would like to pitch in. I am a happy user, but have gone beyond read-only
With little effort i use activehash as a simple file based db. For very similar reasons that the project was created for.
Ie very small data, with little change
migration of data from dev->production (ie checking files in)

I have written a small cms and use ActiveHash files as store. All edits happen on developer machines and so content changes flow in the same way as code canges.
I would be happy to contribute code if the project maintainers want to go to read/write

[kbrock]

@rubydesign is there a reason why you don't want to use active record and SQLite?

If the discussions are any indication, it seems many users want to go in this direction. I was curious for the reason. Understanding the reasoning is the best way to properly meet those needs.

Then we can possibly update the goal in the Readme. We can also use this to guide our future direction

[kbrock]

On my current project, we use fixture files snd populate Postgres using rake db:seeds.

[rubydesign]

@kbrock Thanks for asking, i did not expect this to be picked up. But as i said, i am a happy read/write user and would be happy to contribute back. For me the functionality has been very helpful.

My use case is quite simple, the data is generated in development/staging environments. So db is not an option. Files are useful because the whole development process works around files.

Then the question is, why do i generate data in development/staging. I think the answer is very very similar to the original project use case.
Two concrete examples, mine and one i have run into before

• in my use case i have content writers create static content. Since they are not devs, i can't give them haml to work on. I built a mini cms that uses ActiveHash as a db. My cms is basically a bespoke yaml editor. The yaml goes into git and ends up on the site, like any other changes.
• Translations are another use case. I have built many multi-lingual sites and it is always a pain to keep translations in sync. Again non-devs would do the translation in a dev/staging system. Again edit yamls in a very bespoke way.

My needs are currently met in a single-user, non threaded implementation. Ie upon change i write all files out.
https://github.com/FeenixMakers/merged/blob/main/app/models/merged/active_base.rb#L35
I've tried to keep the AH changes in that file. There are other "models" there that are based on AH, they are close enough to AR to work in basic crud controllers.

[kbrock]

@rubydesign thanks.

• You run a server locally and people use that server to add/edit values.
• Then you go to that server and commit the yaml file into git
• git pull in production
• Production runs off of the yaml
• Production does not change the yaml files.

That makes sense.

Storing yaml text data in git handles merge conflicts better than a bin file. So it would require adding imports and exports and a bunch of complexity.

I've only ever used active hash for developer edited yaml files. My current team uses pot (via gettext) files for translations which are used across many ruby gems, languages, and frameworks.

I just look at the complexities we are adding around mutexes, defaults, or quicker id generation. The new use cases seem like we're duplicating a standard rails database adapter.

[rubydesign]

@kbrock That's the use, mostly, yes. And it is very useful (for me at least). I would imagine for translations too.
The use cases have make the system usually single threaded, single user. A little really goes a LONG way.
Conceptually it is a step along the db adapter, yes. But i tried writing one of those once and the basic crud is really just the small tip of the iceberg. I mean in reality it's nothing like a db adapter, at least in terms of effort.

Really a simple save for a collection would be enough. If you look at the method i linked, that's does a lot. I never understood why i have to do a reload there, but that simple save would be a good start that goes a long way.

PS: sorry about the intermittent communication, i am in the mountains of Tuscany and there is surprisingly bad network coverage.

[flavorjones]

I'm not a very active maintainer at this point, so feel free to discount my opinion; but I think it's a very bad idea to try to turn this gem into a transactional database. That is surely going to be a ton of work to do correctly, and will greatly increase the demands on the maintainers and the support burden (and I'm personally not prepared or willing to take that on).

If people need something more advanced than a yaml file then I would strongly recommend looking into using a sqlite database that can be deployed with the app.

If anyone feels super strongly that they want to go in this direction: would you consider forking this project to try to support those more advanced use cases, rather than introducing that complexity here?

[kbrock]

Hey @flavorjones

My issue is that we seem to already be going in this new direction.
And it scares me. I'm curious if that is intentional.

examples:

• introducing a mutex Add thread safety to ActiveFile #229
• quicker id creation Speed up automatic id definition #231
• creating a json datasource. Records cannot be added to an empty ActiveJSON datastore #203
• some default field behavior that doesn't modify base data hash (can't find)

A read only database probably doesn't need a mutex or id creation. Right?

I wanted to know if others felt we were starting to veer in this new direction and see how they felt about this.

[rubydesign]

Ok, since i have been pro saving here i just want to retract that. I fully understand that open source is collaboration and not making feature requests and don't want to add to anyone's burden.

It just took me a couple of days to rewrite everything that i need, which includes save. Not multi threaded, and no ActiveRecord relations. just 140 lines of dense code that does what i need
https://codeberg.org/breeze/breeze/src/branch/main/app/models/breeze/active_yaml.rb

Thanks for the code/ideas i lifted and the code i used before. (torsten out)

[kbrock]

@rubydesign sorry I didn't reply sooner. That turned out nicely.

I would have thought you'd just go towards using a sqlite database and stock ActiveRecord, but this looks like it meets your needs well.

[rubydesign]

Yes, remember i needed the text files. For my "developer cms" that integrates into git workflow. I finally managed to publish it, thanks again for the hand up.

https://rubygems.org/gems/breeze_cms
https://www.ruby-toolbox.com/projects/breeze_cms