Is it time to redefine the purpose of ActiveHash?

[kbrock]

Is it time to redefine the purpose of ActiveHash?

[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 #229
• quicker id creation #231
• creating a json datasource. #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/FeenixMakers/staged/src/branch/main/app/models/staged/active_yaml.rb

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