Google flags Immich sites as dangerous

Be sure to see the team's whole list of Cursed Knowledge. https://immich.app/cursed-knowledge

The Postgres query parameters one is funny. 65k parameters is not enough for you?!

As it says, bulk inserts with large datasets can fail. Inserting a few thousand rows into a table with 30 columns will hit the limit. You might run into this if you were synchronising data between systems or running big batch jobs.

Sqlite used to have a limit of 999 query parameters, which was much easier to hit. It's now a roomy 32k.

COPY is often a usable alternative.

Right, for postgres I would use unnest for inserting a non-static amount of rows.

> PostgreSQL USER is cursed > The USER keyword in PostgreSQL is cursed because you can select from it like a table, which leads to confusion if you have a table name user as well.

is even funnier :D

In the past I've used batches of data, inserted into a separate table with all the constraints turned off and using UNNEST, and then inserted into the final table once it was done. We ended up both batching the data and using UNNEST because it was faster but it still let us resume midway through.

We probably should have been partitioning the data instead of inserting it twice, but I never got around to fixing that.

COPY is likely a better option if you have access to the host, or provider-specific extensions like aws_s3 if you have those. I'm sure a data engineer would be able to suggest a better ETL architecture than "shove everything into postgres", too.

Some of these seem less cursed, and more just security design?

>Some phones will silently strip GPS data from images when apps without location permission try to access them.

That strikes me as the right thing to do?

This kind of makes we wish CURSED.md was a standard file in projects. So much hard-earned knowledge could be shared.

Huh. Maybe? I don't want that information available to apps to spy on me. But I do want full file contents available to some of them.

And wait. Uh oh. Does this mean my Syncthing-Fork app (which itself would never strike me as needing location services) might have my phone's images' location be stripped before making their way to my backup system?

EDIT: To answer my last question: My images transferred via Syncthing-Fork on a GrapheneOS device to another PC running Fedora Atomic have persisted the GPS data as verified by exiftool. Location permissions have not been granted to Syncthing-Fork.

Happy I didn't lose that data. But it would appear that permission to your photo files may expose your GPS locations regardless of the location permission.

I think the “cursed” part (from the developers point of view) is that some phones do that, some don’t, and if you don’t have both kinds available during testing, you might miss something?

How does it makes sense?

> JavaScript date objects are 1 indexed for years and days, but 0 indexed for months.

I don't disagree that months should be 1-indexed, but I would not make that assumption solely based on days/years being 1-indexed, since 0-indexing those would be psychotic.

It's not if it silently alters the file. i do want GPS data for geolocation, so that when i import the images in the right places they are already placed where they should be on the map

Why so? Months in written form also start with 1, same as days/years, so it would make sense to match all of them.

For example, the first day of the first month of the first year is 1.1.1 AD (at least for Gregorian calendar), so we could just go with 0-indexed 0.0.0 AD.

You know you can just start doing that in your projects. That's how practice often becomes standard.

Was MERGE too slow/expensive? We tend to MERGE from staging or temporary tables when we sync big data sets. If we were on postgres I think we'd use ... ON CONFLICT, but MERGE does work.

With the Nextcloud app I remember having to enable full file permissions to preserve the GPS data of auto-uploaded photos a couple of years ago. Which I only discovered some months after these security changes went into effect on my phone. That was fun. I think Android 10 or 11 introduced it.

Looking now I can't even find that setting anymore on my current phone. But the photos still does have the GPS data intact.

The only reason I can think of to 0-index months is so you can do monthName[date.getMonth()] instead of monthName[date.getMonth() - 1].

I don't think adding counterintuitive behavior to your data to save a "- 1" here and there is a good idea, but I guess this is just legacy from the ancient times.

Saw the long passwords are cursed one. Reminded me of ancient DES unix passwords only reading the first eight characters. What's old is new again...

That would have a better solution in a date.getCurrentMonth(), in my opinion.

> That strikes me as the right thing to do

Yep, and it's there for very goos reasons. However if you don't know about it, it can be quite surprising and challenging to debug.

Also it's annoying when your phones permissions optimiser runs and removes the location permissions from e.g. Google Photos, and you realise a few months later that your photos no longer have their location.