| Field Definition | TypeScript Type | PostgreSQL Type |
|---|---|---|
| { type: String } | string | varchar, text, bigint, numeric, ... |
| { type: ID } | string | varchar, text, bigint, ... |
| { type: Number } | number | int, bigint, doube, ... |
| { type: Date } | Date | timestamptz, timestamp |
| { type: Boolean } | boolean | boolean |
| { type: EnumType<"a" | "b">() } | "a" | "b" | varchar, text, ... |
| { type: EnumType<42 | 101>() } | 42 | 101 | integer, ... |
| { type: EnumType<MyEnum>() } | MyEnum | varchar, text, integer, ... |
| { type: YourCustomType } | see /pages/05UZ44mjyfabZnuevqwM | jsonc, bytea or anything else |
await Promise.all([
+ EntInverse.selectBy(vc, { type: "user2topics", id1: "123" }),
+ EntInverse.selectBy(vc, { type: "user2topics", id1: "456" }),
+]);
+await Promise.all([
+ EntInverse.selectBy(vc, { type: "user2topics", id1: "123" }),
+ EntInverse.selectBy(vc, { type: "user2topics", id1: "456" }),
+ EntInverse.selectBy(vc, { type: "topic2comments", id1: "789" }),
+]);
+The changes happened at "W" will be visible at "R"
At "R", Bob will likely not see Alice's changes made at "W"
Bob and Charlie at "R" will see Alice's changes made at "W"
If only viewCount() was running against the main database, not Redis...
redis.get() calls resolbe in different macrotasks...
await EntComment.select(vc, { topic_id: "123" }, 1000);
+There is no such thing...
...This is what it we do instead
Hellow, +!
+``` + +Thousands of projects were written this way. + +Type 3 JOIN is not much different conceptually. + +Think about the data duplication such JOINs produce over the wire. Consider the following query: + +```sql +SELECT + comments.id, + comments.text, + users.id AS author_id, + users.name AS author_name +FROM comments +JOIN users ON users.id = comments.author_id +``` + +The resulting data that is sends from the database server is: + +| id | text | author\_id | author\_name | +| -- | ------- | ---------- | ------------ | +| 1 | hello | 42 | Alice | +| 2 | my | 42 | Alice | +| 3 | dear | 42 | Alice | +| 4 | friend | 101 | Bob | +| 5 | bye now | 101 | Bon | + +Does it hurt your sense of engineering perfection? Does it smell to you? + +1. The author\_id+author\_name pair of values (42+Alice) is repeated 3 times in the payload for the first 3 comments, and then 101+Bob is repeated 2 times for the last 2 comments. Imagine now that `users` table has way more columns in practice. +2. Another smell is that "author\_" prefix: although being minor, it's clearly a naming boilerplate. You need to introduce some naming mapping convention between the column names in the JOIN result and in your ORM objects (be it glueing parts with "\_" or with "." or whatever). + +Such things are more related not to real resources utilization (the difference is marginal), but to the design and architecture smells. + +## Round Trip Latency Consideration + +To be fair, there is still one benefit in using type 3 JOINs: when you fetch comments, topics and users all at once, you only have 1 round-trip to the database server: + +```sql +-- Traditional ORM's way: 1 round-trip. +SELECT * +FROM comments +JOIN topics ON topics.id = comments.topic_id +JOIN users authors ON authors.id = comments.author_id +JOIN users creators ON creators.id = topics.creator_id +``` + +I.e. you send 1 request and get 1 response (with duplicated data, but anyways). + +If your backend-to-database network connection is slow (like one query takes 50 ms, which happens in commerical and highly vendor-lock-in prone solutions), then such consideration is significant. + +So, in slow networks, JOINs win over the Ent Framework's automatic batching approach: + +```sql +-- Ent Framework's way: 3 round-trips. +SELECT * FROM comments WHERE id IN(...); +SELECT * FROM topics WHERE id IN(...); +SELECT * FROM users WHERE id IN(...); +``` + +What's the catch? + +50 ms for a database query round trip is not a norm. That's the catch. + +In real life (and since 1990x), your network to the database is **not** slow. Quite the opposite, it is very fast, and you have sub-millisecond latency. Otherwise your entire backend becomes just so painfully slow in all other places that you can't manage it. + +Databases are designed to serve queries, do it fast, and with low latency at high concurrency. This is what the databases are for. Let's use the microscope for science and not to hammer nails. + +* False assumption: 50 ms database query is a norm; JOINs are to minimize round trips and solve [N+1 Selects](/getting-started/n+1-selects-solution) problem; take my money dear Vercel & Co. +* Reality: you have troubles with your app design if the query latency is longer than 1-2 ms; round trip time does not affect latency much in case the queries are batched. + +To learn more about batching, "parallel calls", and how event loop works in Node, check out [Loaders and Custom Batching](/advanced/loaders-and-custom-batching) article. + + diff --git a/docs/type-aliases/AfterMutationTrigger.md b/docs/type-aliases/AfterMutationTrigger.md new file mode 100644 index 0000000..4fc73ed --- /dev/null +++ b/docs/type-aliases/AfterMutationTrigger.md @@ -0,0 +1,28 @@ +[**ent-framework**](../README.md) + +*** + +[ent-framework](../globals.md) / AfterMutationTrigger + +# Type Alias: AfterMutationTrigger()\