Proposal: Migrate Android Database from SQLiteOpenHelper to Room

[vijay2909]

I propose we migrate the local database from the current SQLiteOpenHelper implementation to the Room Persistence Library. This would give us significant advantages, including:

Compile-time SQL verification to catch errors during development, not at runtime.
Reduced boilerplate code, making the data layer easier to read and maintain.
Seamless integration with Flow/LiveData for building a more reactive UI.
Aligning the project with modern Android development practices recommended by Google.

My proposed plan would be:

• Add Room dependencies.
• Create @Entity classes that exactly match the current DB schema (version 17).
• Implement the @Dao interfaces and the RoomDatabase class.
• Implement a safe migration strategy to ensure no data loss for existing users.
• Refactor the existing database calls to use the new Room DAOs.

I'm opening this discussion to get feedback on this proposal. If you agree with this direction, I would be happy to start working on a Pull Request. Please let me know your thoughts.

[TheLastProject]

Hey, @vijay2909, serious question for a moment: are you just trying to spam PRs as quickly as you can for Hacktoberfest? Because this is getting really quite disruptive.

You have:

1. Made a PR to fix some cursor leaks
2. Made a PR that makes database changes (and thus has a merge conflict)
3. Are now suggesting to make a new PR which would likely make PR 1 obsolete.

Please be aware that reviewing changes takes a lot of time and effort for me and that I'm doing this unpaid in my spare time, Catima has more than 125 thousand active users, I have to be very careful to not make any mistakes, but you're throwing (conflicting!) changes over the fence at absurd speed. I really don't want to review PRs whose code is going to be obsolete 24 hours later (refactoring sometimes happens, that's fine, but a PR should be worth the time).

I don't think migrating to Room is necessarily bad, the DB class is painfully complex and fragile, but please take a moment to:

1. Decide a general plan you want to do
2. Make sure you don't submit multiple PRs that touch too similar things and are too big in scope, causing merge conflicts or extremely difficult reviews

I'm also seriously worried your PRs may be LLM-generated ("AI-generated" most would say, but there is no intelligence in LLMs) due to how big and all-over-the-place some of the changes are. If they are, please stop submitting them, the risk of serious hidden bugs is way too high in LLM code.

[vijay2909]

Hey @TheLastProject , I’m really sorry for the disruption I’ve caused. You’re absolutely right, I should have taken more time to properly plan out the scope and sequence of my changes instead of rushing multiple PRs.

I genuinely wasn’t trying to spam for Hacktoberfest — I’m still learning how open source collaboration works, and I got a bit carried away with enthusiasm.

I understand that reviewing PRs takes a lot of your time and that stability is critical for a project like Catima. I’ll slow down, plan things more carefully, and make sure future contributions are well-scoped and discussed before opening a PR. Thanks for taking the time to explain this — I really appreciate it and will learn from it.

[vijay2909]

Recently, I’ve been working on the ImportExportActivity, which contained three FIX ME comments. During the process, I also identified an issue where data was being lost on configuration changes. I’ve addressed this by introducing a ViewModel for state management and WorkManager for handling background tasks.

These changes do not affect any database-related components. However, I must admit I’m a bit concerned about receiving negative feedback based on my previous submissions.