Indigo Client colors 7.4.1

Hi Matt, Jay,

first of all thanks for the 7.4.1 update.
I have 2 minor glitches with this update: After I managed to rewrite the Applescripts to Python finally , I updated from 7.3 to 7.4.0 and immediately after that to 7.4.1
1. The SQL Logger database got corrupted during the process and I had to delete the sqllite datbase. After that the SQLLogger seems to run fine again
2. The color of the indigo client is much darker as it used to be. This might be caused by the fact that I am still running the server on Mavericks and it is connected to the changed for dark mode. It simply looks odd and the Indigo client now looks somewhat odd.

Just thought I let you know.
Cheers
Wilhelm

Just on SQLite. If you start from scratch spend 5 minutes to switch to Postgres. It’s is very simple

Download the app, install, switch to postgres in indigo.

It is much more stable.

Karl.


Sent from my iPhone using Tapatalk

Thanks Karl,

I switched to Postgres now. We'll see how that works out.
Now there's only the darker grey windows left, but I suppose I will have to live with that.
Thanks

Wilhelm

[matt (support)]

We had to make lots of UI changes to support Dark Mode on Catalina, including more use of macOS default control/view background colors throughout the UI. On older macOS versions they (Apple) renders some of these pretty dark. On newer macOS versions they are lighter. We don't be trying to tweak macOS's default colors for optimal appearance on older macOS versions since it would require special cases and more complexity (and QA).

I switched to Postgres now. We'll see how that works out.

.. and add a daily backup action:

postgres --> sqldump --> zip file & keep 1..3 days of backups

the indigo utilities plugin has an action that does that for your

Karl

Thanks Karl,

I think performance wise the Postgres server helps a lot!
Your suggestion about backups: I backup using Timemachine. Are you suggesting a timemachine backup of the complete machine doesn't work for Postgres?
Cheers
Wilhelm

Time machine is too slow to backup any dB. And it is not consistent. While backing up the files change. The right way to do this is to do an sqldump. That file is consistent and can reinstall the complete dB as is




Sent from my iPhone using Tapatalk

Ok, thanks.

[jay (support)]

Time machine is too slow to backup any dB. And it is not consistent.

More specifically, if some process opens and keeps open a file, making changes randomly, then a timemachine backup will likely not correctly back the file up because it may not be in a stable state at the time it's read. Indigo doesn't do this: we load the entire Indigo database into memory and make changes to it there, and we periodically flush the changes to disk. This makes it safe for time machine to back up with minimal potential data loss (only changes between the time the change is made in Indigo and the time it flushes to disk).

SQL Lite generally works that way also. Postgres, like MySQL and other more powerful DB systems, don't do this so it's harder to get an external process like time machine to automatically back up. By flushing the DB to a file (i.e. sqldump) you're more guaranteed to get a good backup file that you can then import separately upon recovery.

Not sure I agree with the too slow statement - I've never had an issue with speed since time machine just automatically runs periodically in the background. But I also don't have a ton of data getting written every second like some of you have. I've also never had consistency problems other than permission issues upon recovery, and that issue is more with the process that recovers (Migration Assistant) the backup rather than the backup itself.

Hi Jay,
thanks for your comment.
I would think as well, that a DB server that cannot be backed up by a system tool like Timemachine is bad design.
But in all fairness, I think the operating system should cope with something like that, like volume snapshot on Windows.

Nevertheless I am greateful for the hint that Postgres has such flaws and how to handle it.
Cheers
Wilhelm

[jay (support)]

Oh, it's not a flaw (and certainly not an operating system flaw, as it would happen on Windows or Linux as well), but rather a design requirement of high-volume database applications. They need to read/write data constantly, which means they need to access the disk constantly. There are a variety of backup strategies in high-volume applications like that, none of which are real-time filesystem-based backups like Time Machine. Consumer applications just don't usually need that kind of high-volume system. Postgres (and MySQL, etc) are not really consumer-level applications but are rather server apps, which explains the backup process differences.