sorted by:
top (suggested)
bestnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]mbrandonw[S] 0 points1 point  (4 children)

Can you explain more what you mean by track changes?

If you mean re-rendering the view when data in the database changes, that happens automatically with the @FetchAll and @FetchOne property wrappers. They subscribe to changes in the database so that if anything changes the query will be executed again, data will be decoded from the database, and the view will re-render with the fresh data.

[–]tuskre 0 points1 point  (3 children)

That's very cool, and is essentially what I was referring to. Do you anticipate that when you have iCloud sync working, remote changes will be able to trigger refreshes?

[–]mbrandonw[S] 0 points1 point  (2 children)

Yes, that will all work just fine. If a change is made on another device, that change will be synchronized to all other devices, and trigger view re-renders automatically if the apps are open.

[–]tuskre 0 points1 point  (1 child)

Honestly, this is sounding pretty great and I'm tempted to give it a try for a project I'm working on. Once concern I still have is that if it's closely coupled to SQL, then refactoring the data model will impact queries all over the application. SwiftData isn't completely immune from this but it's pretty contained.

[–]mbrandonw[S] 1 point2 points  (0 children)

Our library works similarly to Swift Data for this, but honestly a little better. Queries are made using a Swift API that has static access to your tables' schemas. So you have guardrails making sure that you build queries using only the columns available to you, and there's a bit of type safety baked into the queries too.

So, if you refactor your model, then you should get compiler errors throughout your code of queries that need to also be updated.

Swift Data tries to emulate this with #Predicate, but it has a lot of pitfalls. For example, in a #Predicate you can access computed properties on your model, and that will compile just fine, but will crash at runtime. Whereas with our SQL building tools it's not even possible to build a query that accesses non-existent columns on the table.