Comments (10)
A change to this just hit master. There may be some edge cases left to support but a straightforward db.select(star()).from(..)
with different joins should just work.
from mammoth.
Do you mean a type for a row from that table, or the user table in the db instance?
Regarding the type of the table itself, I generally pass the whole Db instance around and use it in some sort of repository where I then access those tables.
from mammoth.
Whoops, I meant a row from the table.
from mammoth.
Check. There is not a clean way to get the resulting row from a specific table. There is some internal tooling to get the type from a query though. Conceptually I think this is closer to what is actually happening: queries are returning rows and they may or may not match all the columns of a table, right?
What I sometimes do if I want the row from a specific query in a type, and I keep this type in the same module, I put the query in a function and call type Foo = ReturnType<typeof myQueryFn>[number]
.
As a helper, Mammoth could return a type e.g. TableRow
to help you with your use case though. I do wonder why you don't want the type from the query though. What do you think?
from mammoth.
I want a User
type that is equivalent to a single row in the "users" table. I pass that object around sometimes and so I need something to put in function signatures.
Currently I'm defining User
manually, but I want to ensure it doesn't diverge from the actual DB table type.
The ReturnType
thing could work if there was some way to do SELECT *
, e.g.:
async function selectStarFromUsers() {
return await db.selectStar().from(db.users);
}
type User = ReturnType<typeof selectStarFromUsers>[number] // Also need to unwrap the `Promise` somehow...
from mammoth.
Currently I'm defining User manually, but I want to ensure it doesn't diverge from the actual DB table type.
That's great. As long as you have it map from the a Mammoth return value somewhere it's at least going to break if it's diverging.
Because it's a little annoying to manually type the table in your own type again, I added TableRow<T>
. This doesn't omit the id, or do anything opinionated. If you want that you'd have to do it yourself.
For example, the get the type of a row from table foo you can do this:
export type Foo = TableRow<typeof foo>;
export const foo = defineTable({
id: uuid().primaryKey().default(`gen_random_uuid()`),
createDate: timestampWithTimeZone().notNull().default(`now()`),
name: text().notNull(),
value: integer(),
});
from mammoth.
Also, in the next version you'll be able to use the .star()
e.g.:
db.select(db.user.star()).from(db.user);
which will produce the below SQL
SELECT user.* from user
and automatically give you the whole type as a result.
from mammoth.
TableRow
is what I was looking for, thanks!
Tangent about .star()
: what if someone has a field named star
? Maybe something like db.user.STAR
or db.user['*']
is safer. (Not a major issue for me, just wanted to raise the concern.)
from mammoth.
You are right. This creates a possible collision. Perhaps db.select(star(db.user)).from(db.user)
is a better alternative? db.user['*']
is also possible and close to SQL but it looks so ugly. :|
from mammoth.
Since star
is a common word, I think some people (like me) would use a qualified import, e.g.
import * as mammoth from '...'
...
db.select(mammoth.star(db.user)).from(...)
That's not so bad.
Also, there's the full SELECT * FROM ...
and the table-specific SELECT t1.*, t2.f1 FROM ...
. Not sure if it's worth addressing both of those.
from mammoth.
Related Issues (20)
- ON CONSTRAINT name cannot be a parameter token HOT 1
- select where not like HOT 3
- Next package publication? HOT 5
- Support empty strings for DEFAULT HOT 2
- How to declare `IDENTITY` columns? HOT 2
- orderBy alias HOT 7
- Alias coalesce column HOT 4
- Automatically resolving schema and relationships directly from the database HOT 2
- Temporal tables
- Mixing `raw` with `Expression` values.
- `Array<Token>` is assignable to `Token`
- Way to associate additional metadata with schema?
- Support custom types
- Generated SQL for WHERE clause doesn't match AST nesting HOT 1
- How can we help Mammoth 2.x move forward?
- guidance for Date objects
- How to configure db.count() to return a `number` type?
- Query inside jsonb
- CASE statements don't include the `CASE` and `END` keywords
- Option for `.as()` output to be wrapped in double-quotes? HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from mammoth.