dventimihasura

So does ignorance.

Sounds like the answer is, "No, I would prefer to be unaware as I go my renovations."

Whoever put it there isn't answering any questions, and neither are the people who made it load-bearing later, if they're not alive anymore. No, the question is for you. If you owned this property, would you want to know about the work done by the people who came later and made it load-bearing, or would you rather remain unaware as you go about your renovations?

"Why it was there" is something that matters to people, plural. Knowing why it was for some people doesn't rule out the possibility that you don't know why it was there for other people.

> It is extremely probable that we have overlooked some whole aspect of the question

https://www.reddit.com/r/ProgrammerHumor/comments/q9x1d2/ask...

> I could easily tell why it was there: it was part of a partition for a closet.

> Except that over time it had become accidentally load bearing

> through other (ill conceived) changes to the structure this stud was now helping hold up the second floor of the house

Evidently, you couldn't easily tell why it was there. Moreover, I'm not persuaded that it accidentally became load bearing. It seems quite plausible that it deliberately became load bearing, for reasons which are ill conceived to you but not to the people who had them.

The purpose of college is for its students to learn to relate to other people who went to college.

What economy would you propose for a downtown core of tall office buildings in an American city post-pandemic and post-remote-work?

Detroit never came back to what it was, but it became something different and in many ways it's better than it was at any other time in the last 50 years.

Some people might regard having one fewer moving part to be a benefit of just doing it in the database.

I wonder where you get your confidence. In my experience as a software engineer in the Bay Area for 25 years, every company I've worked at (all medium to large either ISVs or internet companies) used Jira and at every one of those companies Jira was used most heavily by software engineers.

You buried the lede:

https://arxiv.org/pdf/2305.10601.pdf

Sounds like a lot of work blocking all those ads.

Did the author of the parent comment confess to surprise?

It's unusual to require or even ask for personal information joining name, email, and phone number to register, especially for a free site from an untrusted source. There's no way I'm putting my information in there.

Why does it use port 5432 by default? That's the default port for PostgreSQL. Does this use PostgreSQL?

Thanks!

Question: How is pgvector applied in this way different from and maybe superior to the PostgreSQL cube extension?

https://www.postgresql.org/docs/current/cube.html

The cube datatype also stores arrays of numbers (cubes or vectors, same thing) and has functions/operators for computing distance. Granted, they're slightly different, with no direct substitute for cosine distance, but on the unit sphere the cosine distance, inner product, and Euclidean distance have direct correspondences.

> why not just accept SQL

I wish. Unfortunately, sometimes a stateless HTTP REST API is simply a non-negotiable business requirement.

"When I work with TRIGGERs, which is rare"

Evidently, even some experts do use triggers.

"I normally limit them to at most one per operation per TRIGGER"

Great! So do I! So far so good. I guess I'm still in the good graces of some experts.

"in full ANSI/ISO SQL, we do have schema level constraints, the CREATE ASSERTION statement, but that is another topic"

Not in PostgreSQL, we don't. Evidently some experts may not be perfect experts.

It doesn't. I wasn't addressing "coupling your application schema to your database schema." I was addressing "change how the underlying storage of your data looks but don't want to change the end user API" in the parent comment.

> It seems like you built a layer of indirection to specifically allow the thing you said you didn’t want to do a couple posts up

No, because my layer of indirection is in the database in the form of views and procedures. I could be wrong, but I took "coupling my application schema to my database schema" to be something like "having your HTTP API depend on objects in the database", which it does because of the way that postgREST works. If that's the kind of coupling we're talking about, then that's the kind of coupling I would rather embrace than avoid.

They are considered that by whom? Not by me, they're not. Personally, I've never encountered a complex trigger hierarchy and I see no good reason why I ever would, and I write lots of triggers. But, that's just me. Your results may vary.

PostgreSQL + PostgREST IS my "API backend." They're one and the same. There are no other layers. Using an ORM would ADD a layer, not subtract one.

Perhaps what you're asking is, "Why not just have your user interface connect directly to PostgreSQL and issue SQL statements?"

I have a layer of indirection between my end user API and my underlying storage, so that I can change the storage without changing the API. There's no pain involved.

Why don't you want to write triggers?

I don't want to avoid that.

I consider that to be misleading selective editing. Here's a more faithful representation of that missive:

> For the back-end, Apollo Server absolutely can be beat by tools that don't require you to write any code:

> https://supabase.com/blog/pg-graphql

> https://www.graphile.org/postgraphile/

> https://hasura.io/

The careful reader will note that I presented three alternatives, with the one provided by my company last. Moreover, what I wrote is in fact a matter of fact. If you wish to have a GraphQL server without having to write server code to do it, as fine a product as Apollo is you cannot use Apollo to do it because that's not what Apollo does.

Why? No, seriously. Why? Have I tried to persuade people to use Hasura? No. Have I tried to persuade people that it's good or better than the competition? No. In fact, I only mentioned it in equal terms along with two other competitors, which I DON'T work for (Postgraphile and Supabase, both good products).

What I have done is present not matters of judgment, but matters of fact.

Fact: Apollo is not _the_ GraphQL company.

Fact: Apollo isn't the only one with a GraphQL client library

Fact: Apollo isn't the only path to creating a GraphQL server

As matters of fact, these are either true or false, but readers are free to evaluate which they are on their own. They shouldn't trust me, because I'm a stranger on the Internet. But then again so are you and so are most or all people here.

You say that if I don't disclose who I work for people will trust me less. That's silly, because people here shouldn't trust me at all, nor should they trust you, or anyone else, for the reasons I just gave.

In short: don't accept without careful scrutiny anything you read on the Internet, no matter who says it.

Ok. Thanks for that clarification.

In any case, your requirement can be satisfied by SQL views, which transform the persisted model (tables), and which are 'below' the GraphQL server.

First, let's take these two propositions.

> Say you have a web app, an iOS app and an android app

and

> let’s say the model of the data that makes sense for the purposes being the UI for these apps is different from the model that’s used to persist data

Question: If we stipulate that the UI models are different from the persistent model, are the UI models are different from each other or are they they same? What I mean is this. Do the web app, iOS app, and android app models differ from each other? This is important for my reasoning that follows.