Most active commenters
  • __bb(4)
  • thisislife2(3)

←back to thread

676 points __bb | 15 comments | | HN request time: 0.017s | source | bottom

I recently released v3 of Base, my SQLite editor for macOS.

The goal of this app is to provide a comfortable native GUI for SQLite, without it turning into a massive IDE-style app.

The coolest features are

- That it can handle full altering of tables, which is quite finicky to do manually with SQLite.

- It has a more detailed display of column constraints than most editors. Each constraint is shown as an icon if active, with full details available on clicking the icon.

This update also adds support for attaching databases, which is a bit fiddly with macOS sandboxing.

I'd love to hear any feedback or answer any questions.

1. earthnail ◴[] No.45014961[source]
It would be amazing if it could display UUIDs. SQlite doesn't support them natively, but many people store them as binary blobs.

Jetbrains products realize that these binary values are UUIDs and let me edit them easily.

replies(4): >>45015712 #>>45015789 #>>45016676 #>>45018174 #
2. __bb ◴[] No.45015712[source]
Thanks, I'll make a note of that. It's not a behaviour I've seen before.
replies(2): >>45016053 #>>45022765 #
3. supportengineer ◴[] No.45015789[source]
Sometimes a binary blob contains perfectly printable characters.

A binary blob of 7-bit-clean ASCII still fits within a binary blob.

4. dlachausse ◴[] No.45016053[source]
I see that this software is available for direct sale, the Mac App Store, and through Set App. What is your revenue breakdown from each if you don’t mind sharing?
replies(1): >>45016137 #
5. __bb ◴[] No.45016137{3}[source]
It's a bit too soon to tell reliably, since I've shipped v3 as a new app and it hasn't settled down yet. For v2 it used to be 60% App Store and the remainder direct/Setapp. So far for v3 it is approximately 60% direct, 25% App Store and 15% Setapp.

This is a bit of a shift, but the numbers aren't really stable yet so it's hard to tell if it'll stay there.

replies(1): >>45019076 #
6. klabb3 ◴[] No.45016676[source]
I didnt know there are dozens of us! When I saw the lack of native support i decided to use binary blobs. I mean, why waste many bytes if few bytes do trick? In the SQLite studio app im using its garbled and annoying to browse.

Too bad this is mac only. I mean, im a mac user (among other things) but i don't want to depend on platform specific tooling.

7. da_chicken ◴[] No.45018174[source]
See, I would be terrified of doing that because different RDBMSs and languages store and sort UUIDs differently. A UUID is not just a number. It's a structured data format.

Both MariaDB and SQL Server have dedicated data types for UUIDs, and they sort in an unexpected order if you're unfamiliar with the structure of a UUID or the endianness of certain portions of it. Oracle assumes it's going to be binary, but the generating function SYS_GUID() has some endianness issues you can run into. Meanwhile, PostgreSQL kist sorts them like a string!

Similarly, if you're using .Net to generate a native GUID type and passing that through your RDBMS provider, it may arrive and be stored differently due to that endianness problem.

Expecting that every SQLite database is going to be storing UUIDs in an identical manner seems insane to me.

replies(1): >>45022723 #
8. thisislife2 ◴[] No.45019076{4}[source]
Thanks for offering this app outside of the App Store too. Why don't you support older versions of macOS though? Does this app really rely on any new macOS APIs that it has to be built only for macOS 15+?
replies(1): >>45023007 #
9. throwaway2037 ◴[] No.45022723[source]
Is it incorrect to simply sort the alphanumeric version of UUIDs? I am unsure if UUIDs have special sorting rules like Unicode.
replies(1): >>45034907 #
10. earthnail ◴[] No.45022765[source]
I work a lot with syncing code for mobile apps, and use sqlite for local dbs on the app, which I guess is fairly standard. UUIDs make sync protocols much easier to write.
11. __bb ◴[] No.45023007{5}[source]
One of the things I found limiting in previous versions was supporting older versions of macOS. I’ve decided this time round to only try to support the latest and previous versions. Since the release of Tahoe is probably quite soon, I’m starting with just macOS 15 and will support that and macOS 26 to start.
replies(1): >>45024371 #
12. thisislife2 ◴[] No.45024371{6}[source]
From what I have observed, apps built for macOS Mojave (64-bits) or macOS Catalina all work fine on the latest versions of macOS. So I guess you must be hampered with App Store requirements ...
replies(1): >>45026466 #
13. dlachausse ◴[] No.45026466{7}[source]
Apple frequently introduces new APIs that enable new functionality or make things easier and more maintainable. Also, testing software on older operating systems creates additional work. Unlike other OSes, macOS puts several limitations on running it under a VM, so in some cases you have to boot the OS up on real hardware. If you don't have 5 or 6 old Macs laying around this means setting up multi boot. There are also limitations on which versions the latest Xcode can target.
replies(1): >>45042076 #
14. da_chicken ◴[] No.45034907{3}[source]
It's not really about that.

It's the fact that, as the Base author, you don't really know how a given application might present a 16-byte binary version of a UUID to the database. If you don't know that, how can you reverse it to display the correct string representation? There are complications with byte groups potentially being in different places, and even the potential of mixed byte ordering.

How can Base make a 16-byte binary format that display both a GUID stored from a .Net application from person A, and also a UUID from a Python application from person B, and have the string representation be accurate in both cases? I don't think you can.

15. thisislife2 ◴[] No.45042076{8}[source]
I understand. In this particular case, I am making an assumption that they aren't really using any new OS API's (this is, after all, a reasonably simple app) in which case they could just build and test on macOS Mojave or Catalina (the minimum OS version) and the latest macOS Whatever (the maximum OS version, for the APP store). As I highlighted, most older apps run without issue on newer macOS versions, and so that is a reasonable assumption to make and forego testing on all versions. Then, only if you get some bug report on some particular version, you can test for that ... (as you pointed out, the best approach - testing on all versions - can be very resource intensive, and this can be a practical middle-way approach for an independent developer).