Show HN: SwiftData – A SQLite library in Swift | Hacker News Reader

Show HN: SwiftData – A SQLite library in Swift

github.com

48 pointsgreenbast18 comments

Have you guys seen YapDatabase [1]? It is an awesome Obj-C key/value/collection store (and more) built on top of SQLite, that I originally started using instead of Core Data for its easy SQLCipher support. It's built by the venerable Robbie Hanson [2] who is well known for his previous work: CocoaAsyncSocket, XMPPFramework, CocoaLumberjack, and CocoaHTTPServer.

If you're tired of Core Data, I highly recommend reading the wiki [3] and giving it a shot!

1. https://github.com/yaptv/YapDatabase 2. https://github.com/robbiehanson 3. https://github.com/yaptv/YapDatabase/wiki

I have a friend who uses it in production. He swears by and has tried to convert me. I'm still sticking to CoreData with some categories for syntax sugar, but I've been closely monitoring realm.io for the last couple of days...

Hello,

Is there already a built-in package manager in Swift? Maybe CocoaPods will have support for Swift but, as a completely new environnement, I'm hoping that Apple will add a dependency manager for Swift.

Currently, I'm not aware of one.

However, once Swift comes out of beta (and with some time) I think the best practices to distribute libraries will become evident.

It would be great if Apple released a dependency manager for Swift, though!

I think Apple should build the basic hooks so that package manager like CocoaPods is possible but a better solution will emerge if the package system is handled outside of Apple which is likely have a huge legal that prevents healthy ecosystem.

Xcode 6 provides better support for third-party frameworks, which certainly makes distributing packages without a third-party took like CocoaPods easier, but it doesn't have anything resembling a proper package manager or dependency resolution tool.

Right now, the state of distributing libraries in Swift seems to be "add it as a git submodule, and either add the xcodeproj and link the compiled framework or just drag in the .swift files, but let's hope the community comes up with something better soon".

With both iOS & OSX now supporting frameworks, CocoaPods has the potential of becoming much more elegant. See progress on this here: https://github.com/CocoaPods/CocoaPods/pull/2222

Nice to see some Swift wrappers. I don't like Core Data so this looks like an option when writing iOS apps. For more portable code, here is my C++ wrapper for SQLite: https://github.com/catnapgames/NLDatabase

This is super slick. SQLite is so elegant, and this should stop people from reinventing the wheel over and over again.

I hope somebody reinvents this library.

I know it's hard to release something to the public, and easy to throw stones. But I'm going to do it anyway. I just don't see the “elegance” in this library and I see several problems with this library that make it unsuitable for production use. Examples:

This library provides access to a singleton database. Did you want to choose the location of your database? Sorry, it's going to be “SwiftData.sqlite” in your app's Documents folder (if sandbox) or the user's “Documents” folder (if not sandboxed). Did you want to use a SQLite3 database as your document storage format, and let the user have multiple documents open simultaneously? Sorry, not with this library.

This library doesn't use prepared statements. When you give it SQL with bind placeholders and substitution values, it creates a new string that embeds the values. Does your SQL statement have a string literal containing a `?`? Sorry, this library will treat it as a bind placeholder anyway. (Example: the ? here is not a placeholder: insert into x values ('?')) Did you want to use less error-prone named placeholders, which SQLite3 supports natively? Sorry, not with this library.

This library loads the entire result set of a query into an array and returns it to you. Did you want to reduce your memory footprint? Sorry, not with this library.

The library source code is full of copy-pasted code that should be unified.

Every enumeration case in the standard library (c.f. Bit, Character, FloatingPointClassification, ImplicitlyUnwrappedOptional, MirrorDisposition, Optional, QuickLookObject, UnicodeDecodingResult) starts with a capital letter. This library's enumeration cases (c.f. DataType, Flags) start with lower case letters.

Nice project! anyone know how this compares to using an Objective-C sqlite wrapper like FMDB from swift?

What's the advantage of using something like this over CoreData - which is built in?

Personally, I find the CoreData API unpleasant to use ... I think SwiftData offers simplicity and the familiarity of SQL to developers.

But CoreData is a great option if you have time to learn it!

I've had the same thoughts and internal discussions a few times. I recently found these two articles, one talking about using NSCoding instead of CoreData, and the other is about helper libraries to make CoreData easier to manage. Both are good reads if you're working on iOS apps.

http://nshipster.com/nscoding/

http://nshipster.com/core-data-libraries-and-utilities/

CoreData actually has the option of using SQLite as the underlying datastore. The other alternative is a proprietary binary store. I think there is also an XML store. CoreData is an abstraction level higher than SQLite. It's similar to an ORM or graph database where it manages the relationships between objects for you. So if you don't need all the features of CoreData, SQLite is lighter and simpler.

SQLite is the default storage engine for CoreData.

SQLite ships with iOS and OSX too, just like Core Data. All you have to do is link libsqlite3.dylib instead of CoreData.framework.

Please highlight your swift code examples:

```swift

Reply on news.ycombinator.com