Nope. And not sure where you get that idea. This release even involved a rename away from including "GRDB."
When 0.1 of the library was released, it was a simple adapter between our Sharing library and GRDB, thus the name SharingGRDB. As our needs grew, the tool evolved significantly, and both the Sharing component and GRDB have become more of an implementation detail. In the future we will consider supporting any SQLite adapter, even your libraries ;)
Are you suggesting SQLiteData is an ORM, or SwiftData? SwiftData (and CoreData) are certainly ORMs, but SQLiteData is not. It's simply a collection of tools on top of SQLite that provide similar functionality to SwiftData, but you always have direct access to SQLite.
The things you say that SQLite doesn't do is exactly what SQLiteData provides (Swift-friendly bindings for encoding and decoding data from SQLite), and more. There's a footprint, as there is with any library, but there is no ORM level of abstraction here.
Well, it has things like @Table and wants you to write SQL using Swift syntax. It's good that it lets you bypass this, but it encourages using the wrappers so I think that's going to be most of the usage. Also, if you're going to mostly bypass, then why incur the costs of adopting? The main bypass I saw was #sql, but while you can write SQL, it's a substantially different API than sqlite's C API to do the same.
One problem with data access wrappers is that what's both above it and below it have strong app concerns. The developer needs to understand and control what's below it, so an intermediate abstraction gets in the way. That is, in addition to understanding the lower-level, they also have to understand the intermediate abstraction, and how it maps to the lower level. So it's really best if the API surface is minimal.
What I would want is an API where the core is something like:
where pStmt would be as minimal a wrapper around a sqlite statement as is feasible (maybe even a pointer to a sqlite3_stmt directly?). There might be a minimal (non-existent?) wrapper around the sqlite3 connection too. (The sqlite pointer should be a public member of any wrapper, so you can call any sqlite3_ functions you want).
(I'd want some convenience methods too, that combine bindParameters and readRowColumns with preparing a statement and stepping through it, like sqlite's exec.)
Now, I know this doesn't address CloudKit sync at all, but I think a similarity minimal type-focused binding is best there too. It has nowhere near the 5-star API that sqlite has so there's a better argument for wrapping it, but sync tends to quickly accumulate app-level concerns when it comes to the exact details of sync conflicts, so you might as well keep that at app level. I think there maybe a set of composable convenience methods might do it, to handle the pain points without hiding the details you'll need access to.
Anyway, my point is NOT that sqlitedata is bad, it's that people should be really careful about taking on the costs that it has, and consider whether it will ultimately cause more problems than it solves. Meanwhile, sqlite is world-class -- you want to wrap it as little as possible.
I think you're missing the point. iOS 13 is not the value proposition of the library, it's simply one small feature of comparison of many and isn't highlighted beyond a simple mention. The library provides just as much value if you are starting a new app today and choose to target iOS 26+.
> And with Apple's history of source-breaking changes over major platform updates, plus given how even huge libraries/tools like Alamofire, Realm, RxSwift, Cocoapods eventually succumbed to oblivion, I can't think of why an Apple developer with any modicum of discernment would choose PointFree's tools over Apple's own--unless they are themselves caught by the allure of reinventing the wheel.
Isn't this just a blackpilled take in general? You're complaining that Apple software breaks, that other third party software is discontinued, and this somehow leads to the conclusion to avoid this library?
If you think that through, the answer is: of course! Take for example the move from Swift 1 to 2 (an extreme example but illustrates the point).
If you used a third-party lib written in Swift 1 and you had to move to Swift 2 because the next version of iOS requires the latter. Then you’ll have to wait for the lib developer to publish a version of their third-party lib for Swift 2 before you can publish your app. That’s the same kind of risk that you’re exposed to with source-breaking changes.
Admittedly, source-breaking changes have gotten less frequent in Apple’s major tooling updates, but the right mindset when developing for walled gardens like Apple is that it will happen again.
You appear to have unwittingly made an argument for why to use this library over SwiftData - here you can control your own destiny instead of waiting for bugs to be fixed in the OS frameworks and customers to update.
For those that are worried, the source is there to inspect and compile. For those that aren't, there's reduced friction. It's a young project and I could move the binary elsewhere, but I'm not sure that would change your concern?
I believe GP was saying two separate things. First of all, it's unusual to commit binaries to source control, because they can't be merged, etc. Second of all, he personally isn't comfortable with binaries and would rather compile from source.
Slingshot's supported Retina since V2. Dropbox's auto-upload of screen shots is pretty good (they're using a private API to copy the link the your clipboard before the upload even starts, so it feels really fast), but if you share files outside of screen shots, Slingshot might still fill a need with file and clipboard sharing.
It actually lets you do this already, though the documentation is relegated to a manpage that doesn't get installed automatically. It checks, in order, for:
- $GHI_REPO env var
- git config ghi.repo
- remote named "upstream"
- remote named "origin"
So you can just use "git config ghi.repo username/reponame" to get the behavior you want.
Amazon offers 2 price points, emphasizes the ad-driven one, and somewhat obscures the fact that it's ad-driven. I don't see how that relates to the free (and Creative Commons free content of) marco.org, and the fact that he syndicates ads from a network he trusts there.
If you want to set your login shell to zsh, go to System
Preferences -> Users and Groups. Right-click on your user
account and select Advanced Options. Change the login shell
dropdown to /bin/zsh.
You're better off using `chsh -s /bin/zsh` (or, better yet, `brew install zsh`, append `/usr/local/bin/zsh` to `/etc/shells`, and use that, instead).
But still, where is "6 months" coming from? A vague "year" figure is given by Mark Post (with the caveat that funding is needed), but that doesn't even bring into consideration the process of getting the meat out of the lab and into the grocery store.
I wondered the same thing about the 6 month figure. This is some aggregator site run by the SciFi/SyFy channel? It's the kind of pop science reporting I think is bordering on irresponsible, really. Their source is New Scientist requiring a signup:
I would have loved to have had this a year ago, or two, etc., but my accidental quits haven't been nearly as frustrating since upgrading to Lion. I can still see this being useful, though, especially with apps that are slow to implement resume functionality.
Nope. And not sure where you get that idea. This release even involved a rename away from including "GRDB."
When 0.1 of the library was released, it was a simple adapter between our Sharing library and GRDB, thus the name SharingGRDB. As our needs grew, the tool evolved significantly, and both the Sharing component and GRDB have become more of an implementation detail. In the future we will consider supporting any SQLite adapter, even your libraries ;)