jelly-fin
jelly-fin copied to clipboard
two-jelly-beans
Transaction CRUD
Does the transaction object need to hold information about the user who initially created it?
Yes and no. Yes, we need to associate transactions with users, but I don't think we need to specify that in the transaction object.
What we could do is in the transaction collection, have a top-level entry for users and then input transactions for each user there.
{
user: "random_user_string_here",
transactions: {
{...},
}
}
But, in the future, I'd also like to handle multiple accounts. For alpha, we can just focus on handling one account for now.
At first I thought of: What if we simply create a 'transactions' collection inside the user's document?
But your idea of handling multiple accounts came to my mind too, because that would be a great feature for families, so, in that case, creating a collection inside the user would be a mess because later when we want to handle multiple users we would have to add the same transaction inside the two users. So, what we could do is like create a transactions collection and there add the reference to the user(s) it belongs to.
Or, when we handle multiple users, we can create like "Teams" and there we save their transactions and those stuff.
I'm still not sure about how our approach to that should be so I'm just giving ideas.
Just thought of something else. People usually share finances, so maybe we would have one account with multiple users?
My proposal is that the model for Users & Transactions are many-to-one related.
EDIT: I disagree with myself. Users can have any number of transactions, and transactions have a user (the one who performed the transaction).
Is there any reason not to do this? The extra infrastructure doesn't seem very costly.
Have a collection of accounts, which has a list of transactions.
Then users have a list of accounts. 2 users can have the same account.
Yes, this is a feasible way to implement sharing, I can use my login credentials to access any number of accounts that have been shared with me.
So we restructure everything:
Users Have:
- User ID (unique)
- Username, password, email
- Other optional personal information if we choose to collect it (first name, last name, etc.)
- Account IDs (MANY)
Accounts Have:
- Account ID (unique)
- Original User ID (this is the master user who initially created the account) (ONE)
- Shared User IDs (MANY)
- Transaction IDs (MANY)
- ???
Transactions Have:
- Transaction ID (unique)
- Account associated (ONE??)
- Transaction info (as written in the original issue)
One thing to add,
Payment method is a 2 character string Here are the definitions of each:
ad = auto draft po = pay online bp = bill-pay in = income xf = transfer
We can add more as time goes on, but that's the basis for that field.
We might think of more, I just did.
aj = adjustment cx = cryptocurrency
Amount will obviously be stored as a float. It's probably easier to do positive and negative numbers as that makes it easy to sum.
Accounts Have:
Account ID (unique)
Great idea on 2 users. Shared users could be an array.
Original User ID (this is the master user who initially created the account) (ONE) Shared User IDs (MANY) Transaction IDs (MANY) ???Transactions Have:
Transaction ID (unique)
Yes, I think one is sufficient. Keep in mind, if we do a transfer, we need to have 2 transactions.
Account associated (ONE??) Transaction info (as written in the original issue)
We'll need to store an initial balance somewhere. I was thinking it's easiest to create an "init" transaction for this.