https://www.prisma.io/ logo
Join SlackCommunities
Powered by
hey <!here>! we're currently working hard on the D...
# orm-help
m
hey <!here>! we're currently working hard on the DataModel 2.0 implementation and would love to hear what you think: https://gist.github.com/matthewmueller/506147abee368f0ea028eb036b8a0a68 👉 Chat with us in #datamodel-2
🦜 8
💪 6
😍 3
😎 6
👀 3
🔥 6
prisma cool 6
prisma green 6
💚 4
🗄️ 4
Please take a look at the upcoming changes and let me know if you have any suggestions for further improvement 😄
Also if you'd like to read more about the full specification, you can visit: https://github.com/prisma/rfcs/blob/0002-datamodel-2/text/0002-datamodel.md
i
Wow
That looks really good, the new format. Very readable
🤓 2
m
bravo bravo 😄
🙌 1
v
@@id([ standup, user ])
is very frustrating, though
Is this ID thing really a PK (primary key)?
m
@Vlad Faust yep, it's a primary key over 2 fields. Do you have any suggestions for improvement? 🙂
v
Yes, replace 
id
with 
pk
or 
pkey
🙂
I don't know what syntax is it, but unless 
?
tokens are separated from type tokens, it's hardly readable which one is actually optional. In other languages, e.g. Crystal, nilable types have 
?
highlighted in another color, which is not the case here. I could suggest 
@optional
or 
@nilable
keywords instead
👍 1
m
@Vlad Faust we were considering 
@primary
or 
@key
, but were thinking that'd be too specific to relational databases. how do you feel about the 
@@
syntax?
v
@@
is read as "class-level", which is compared to 
@
, "type-level", so it's intuitive IMO
👍 2
I have Ruby and RDBs background, so I'm a bit biased
m
Ah good call about having 
?
be a different color! we're actually working on the syntax highlighting right now, this gist doesn't have the proper coloring. I think you're right that we should highlight that. I'll take a look at crystal's syntax for inspiration. Here's an early sneak peak at the syntax highlighting: https://cldup.com/X02Ji89inE.mp4
v
Looks nice. I love how you allowed to have emptylines, and how it affects tabulation. Very beautiful
It's 
\t
, am I right?
If you're implementing your own formatting, take care of multiline annotations payload, e.g (I'm not sure abut proper tabulation, think of it):
Copy code
id  Int @sequence(
  name: "badges",
  foo: bar
)
m
currently it's spaced. i'm not sure how good IDE support is for the 
\t
width cause you could have a lot of them. As a Go dev, I prefer tabs though 🙂
v
It's common for editors to auto-convert tabs into spaces, with number of spaces depending on user settings
👍 1
m
yah that should work, we're currently just thinking of line breaks across multiple 
@attributes
, but i think we'll need to come up with something for long parameter inputs as well. we'll probably follow prettier's example of breaking up lines with more than 80 columns.
cool I'll experiment with 
\t
too, I hadn't thought of that 🙂
v
Another thing, I've noticed that 
@sequence
annotation has named arguments, while 
@relation
has explicit named tuple (
{ cool: "ok" }
)
we'll probably follow prettier's example of breaking up lines with more than 80 columns
I'd avoid that. It would bring issues. If user wants, they would break the line for themselves. Most editors have wrapping, also
👌 1
m
Ah yes, good catch. We're still working on the attribute signatures. Right now we're thinking attributes can have 1 unnamed argument.
v
Right now we're thinking attributes can have 1 unnamed argument.
That's the cleanest approach, which would lead to minimal confusion!
No, that's not what I meant
IMO you should have unnamed arguments, but not limited to a single one. 
@id("foo", 10)
is OK. You'd better avoid named arguments, like with 
@sequence
, as it's confused with the 
@relation
example
Okay, it's not that simple, so you should put thought into it 😄
m
we like the idea of named arguments because you could have a ton of optional ones. You could also achieve this with 
@relation({ ... })
. We're definitely still thinking about this so your point is well-received 🙂
Let's continue discussion in #datamodel-2
Open in Slack
PreviousNext
Powered by