[FEATURE] Break db.json to smaller chunks about abbreve HOT 15 CLOSED

As I said, there'd be a solution for handling situations like that.

Also, I believe the whole point of creating a JSON file is to make the contribution process easier (no need to create an extra account, anyone can review new abbrev additions, everything on one platform; GitHub)?

from abbreve.

I love this proposition! I have been going over how to avoid the huge file size. For the structure you proposed in #42 I see the point there. But I would like to prioritize this issue over that one for the time being. Perhaps we can start a branch to work on this. What do you think?

from abbreve.

Sure!

from abbreve.

We can implement this solution now, which means we'd have to create a simple app for restructuring all definitions once the decision is made on an alternative structure

from abbreve.

@Njong392 can you create a new branch for this feature, so that we can start the migration process

from abbreve.

Ok good. I'll create a branch ASAP. Are we going to manually create folders for the new structure you proposed? If so, I suggest we don't tamper with the db.json file. While we work on the fork people will be adding contributions to it. Deleting it will cause serious merge conflicts.

from abbreve.

@Njong392 can you create a new branch for this feature, so that we can start the migration process

I have created a branch called structure for the migration. If you have any other questions, do reach out.

from abbreve.

Breaking the data down into individual files is a good idea! Only problem I can think of is the abbreviations that can't get transformed into a file so easily. Take this for example:

"w/o": { "definition": "Without" },

We could for example use an underscore to check for spaces and something else to check for slashes. Just something to keep in mind.

from abbreve.

@Njong392 can you create a new branch for this feature, so that we can start the migration process

I have created a branch called structure for the migration. If you have any other questions, do reach out.

Sure! I'm out atm would start working on it as soon as I'm back

from abbreve.

@mathiasayivor
If I understand correctly, each abbreviation should have it's own json file?
If that's the case, my only question is this. Wouldn't that be too many json files? Assuming each acronym is independent

from abbreve.

@mathiasayivor If I understand correctly, each abbreviation should have it's own json file? If that's the case, my only question is this. Wouldn't that be too many json files? Assuming each acronym is independent

Yes, but it makes sense to do so based on our current situation.

Also, I don't think anyone would want to go through the JSON files individually to look for definitions, as it's the equivalence of trying to manually going through an app's database instead of actually using the app.

Secondly, as I stated in the caveats section, we can implement a solutions for managing each JSON file, which I'd start working on soon.

from abbreve.

Breaking the data down into individual files is a good idea! Only problem I can think of is the abbreviations that can't get transformed into a file so easily. Take this for example:

"w/o": { "definition": "Without" },

We could for example use an underscore to check for spaces and something else to check for slashes. Just something to keep in mind.

This is worth noting! Thanks for pointing it out @larsniet

Saw this late...

from abbreve.

@mathiasayivor If I understand correctly, each abbreviation should have it's own json file? If that's the case, my only question is this. Wouldn't that be too many json files? Assuming each acronym is independent

Yes, but it makes sense to do so based on our current situation.

Also, I don't think anyone would want to go through the JSON files individually to look for definitions, as it's the equivalence of trying to manually going through an app's database instead of actually using the app.

Secondly, as I stated in the caveats section, we can implement a solutions for managing each JSON file, which I'd start working on soon.

Well, I just assumed that it would be better to leave it as is pending when a NoSQL database would be implemented. Migration wouldn't be difficult in this case. However if transferring the content of the JSON files to an actual database at a later point in time wouldn't be a problem then It's all good

from abbreve.

Also, I believe the whole point of creating a JSON file is to make the contribution process easier

I agree with @mathiasayivor on this one. There is no need to think of databases for now. Will there be many files? Yes. But nobody will be going through them like he said. It's just a more optimised method for what we have right now.

from abbreve.

Closing this as merged!

from abbreve.