Would the Sharing-GRDB Lib allow me to model Class Inheritance? #12
Replies: 5 comments 2 replies
-
|
Hi @davidakoontz, this library doesn't provide any tools that either help nor hinder using inheritance for domain modeling. However, I will say that I think inheritance is not the way to go for this. It is better to denormalize your schema into separate tables, which is just generally recommended for SQL databases. But also, I'm not sure I see how you are wanting to use inheritance in your current domain, and it seems like SwiftData is more than capable of handling this kind of data. Can you share some actual data types that represent what you want to model? It also seems this question is more about our new SharingGRBD, which uses Sharing but is a separate library. I am going to transfer the discussion to that repo. |
Beta Was this translation helpful? Give feedback.
-
|
Oh... an expert is saying the caveman approach of denormalized schema is recommended - cool! I'm a novice at all of this... but quite sure my DBA colleagues back in the Java days would frown and reject my TWO Transaction table solution. Here's some of my models... Stock model EquityBuyTransaction - very similar to EquitySellTransaction (diff by Kind.Sell) Then this View - AccountsList - which has my Query - that's driving all the SwiftData stuff... Perhaps I'm doing this all "wrong"... but I'm attempting it anyway - and learning. Until the Matrix can give me a download of Swift Design... doing my best. The reason I'm asking about Class Inheritance... One attempted solution I tried with SwiftData was instead of TWO Transaction tables... I was going to have one table and two subclasses of a base Transation Class. Which would have the: Assuming SwiftData could deal with class inheritance... this was to give me the (my assumption) I could pass the base class Transaction to a general TransactionRowView( transaction: Transaction) {..} Let the view figure out if it's Buy or Sell and display the transactions... do the profit/loss math... etc. So all that... to explain why I "think" I want a persistance framework like SwiftData to work with class inheritance. I hope this explains my reasoning... |
Beta Was this translation helpful? Give feedback.
-
|
Happy too... EquitySellTransaction (Just a copy of the EquityBuyTransaction with a change of Kind) to create a 2nd Table in SwiftData. Kind is an Enum - and I maybe persisting this poorly - I've read there are issues with Enum & SwiftData... but a bit beyond my current knowledge... and I don't THINK I care. I found out somehow that I could not use "Type"... THANKS for caring! |
Beta Was this translation helpful? Give feedback.
-
|
You might also care about Account class - which a collection of Accounts is a Portfolio... Used in the View attached. |
Beta Was this translation helpful? Give feedback.
-
|
I recommend a single For the times you need those separates lists, you must query for them separately: import SwiftData
import SwiftUI
@Model
class Stock: Identifiable {
var symbol = ""
@Relationship(deleteRule: .cascade)
var transactions: [Transaction] = []
// Other fields...
init() {}
}
@Model
class Transaction {
var kind: String
// Other fields...
init(kind: String) {
self.kind = kind
}
}
struct StockDetail: View {
let stock: Stock
@Query var buys: [Transaction]
@Query var sells: [Transaction]
init(stock: Stock) {
self.stock = stock
_buys = Query(filter: #Predicate { $0.kind == "buy" })
_sells = Query(filter: #Predicate { $0.kind == "sell" })
}
var body: some View {
List {}
}
}And this is basically the same way you would approach this problem using this library. So it's really up to you how you want to do this. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
I've been working off & on with a Stock App idea. And after many starts and restarts... decided to try a different approach to my killer feature. Instead of working on the Charting of stocks with my personal buy/sell transactions plotted on the stock chart. I changed tacks... thought if I could just get the transactions in the App that charting would flow easily...
Well the first big hurdle I've come to is in modeling the basics of Stocks <-> Transaction ( a 1 to Many relationship ) which SwiftData handles just fine. It is when I split the Transactions by "type" or "kind" ( type appears to be already used keyword) either "Buy" or "Sell" kinds. I could not find a Predicate to put the Transaction in the proper list. I modeled 2 list buyTransation [Transaction] & sellTransaction [Transaction] in the Stock class.
So with the code running I would end up will ALL transactions in each list. Weird! Even though I would enter the transaction in just one list - when fetched the transactions were in both Buy/Sell list.
So I thought - I will have to make a base class Transaction & two inheritance classes BuyTransaction & SellTransaction in the SwiftData model. That did NOT work out. From what I've researched SwiftData does NOT support model inheritance. I don't know if this is still true/valid. I didn't get it to work.
Then I tried a Protocol attempt... not so good either. So then I've done the caveman approach... 2 Transaction tables in SwiftData. It works and allows me to continue design/coding.
So then I saw your release of Sharing Lib. It looks great. Would I have better luck switching persistance strategies mid-stream?
Does your solution allow Inheritance?
I also assume it would be simple SQL to write the Query for BuyTransaction or SellTransaction and use the Enum Kind to distinguish the list.
Beta Was this translation helpful? Give feedback.
All reactions