Multiple issues when running Bonds with PostgreSQL

[b3nd1k]

Multiple issues when running Bonds with PostgreSQL (signup + vault deletion)

I’ve been testing Bonds with both PostgreSQL and SQLite, and it seems there are several issues specific to the PostgreSQL setup.

With SQLite, everything worked out of the box.

With PostgreSQL, I encountered multiple problems during basic usage.

---

1. Signup fails on PostgreSQL

Creating a new account fails with a 500 / "Failed to register" error.

This happens because the table user_notification_channels is created with:

preferred_time timestamptz

But the application inserts a time-only value like:

'09:00'

PostgreSQL rejects this because it expects a full timestamp.

I had to manually change the column type to make signup work:

ALTER TABLE user_notification_channels
ALTER COLUMN preferred_time TYPE time
USING preferred_time::time;

After making this manual change, signup works normally.

SQLite does not have this issue.

---

2. Vault deletion fails on PostgreSQL

After signing in, I created a vault called "Test Vault" and immediately tried to delete it.

The deletion fails with the following foreign key error:

ERROR: update or delete on table "vaults"
violates foreign key constraint "fk_vaults_contacts"
on table "contacts"

The vault was just created and should be empty, yet PostgreSQL still prevents deletion.

This does not happen with SQLite, where vault deletion works normally.

---

Summary

So far the PostgreSQL version required manual fixes and still has issues with basic functionality, while SQLite works without problems.

It looks like PostgreSQL support may need additional testing around:

• Schema types (preferred_time)
• Foreign key behavior when deleting vaults
• Differences between SQLite and PostgreSQL behavior

[naiba]

Thanks for the detailed report.

1. Signup fails — preferred_time type mismatch

Same issue as #67. The model defines gorm:"type:time" which should be correct for PostgreSQL. See my response in #67 for the workaround SQL.

2. Vault deletion fails — ✅ Confirmed bug, now fixed

This was a real bug. DeleteVault only cleaned up 3 tables (UserVault, Contact, Vault) but missed all seed data and contact child tables created by SeedVaultDefaults.

Orphan data left behind:

• 5 ContactImportantDateType records
• 5 MoodTrackingParameter records
• 4 LifeEventCategory records
• 2 VaultQuickFactsTemplate records
• Plus all Contact child tables (Notes, Tasks, Reminders, etc.)

SQLite silently ignores foreign key violations by default, which is why it worked there but failed on PostgreSQL which enforces them.

Fix: DeleteVault now performs a complete cascade deletion of 30+ related tables in the correct FK-safe order. The same fix was applied to AccountCancelService.Cancel which had the identical bug.

The fix will be included in the next release.