Hi guys, I'm running into an "issue" that I am not...
# orm-help
d
Hi guys, I'm running into an "issue" that I am not 100% sure of how to handle. I was able to tackle it, but I wanna see what you guys think. Basically, I have a bunch of tweets. From each tweet I get it's content and the user. The issue is that the user also gives back it's password! To tackle this, I ended up doing this:
Copy code
await prisma.tweet.findMany({
			include: {
				user: {
					select: {
						id: true,
						displayName: true,
						username: true,
					},
				},
			},
		});
I basically decide to take all fields from the user, besides the password. Is this the best way to do it? Since I might be using other models that require me to get the user, doing this on every query seems a bit repetitive. I was thinking I could do 2 things: Have the private info of the user in 1 model and all the public one in another. So the User model would have an id, password and email and the Profile the username, displayName, etc. The second option would be to keep the models as they are and instead just save an object in another file that looks kinda like this
Copy code
{
 id: true,
 displayName: true,
//etc
}
and then just put that in every select so that at least, if the user model changes, it updates in all queries that involve the user.
i
Quick sanity check, it's not a plaintext password, right?
You said password as opposed to password hash or password salt
d
its hashed yeah
this is just a quick random web app im doing to test stuff. I'm doing a small twitter thingy. But yeah, it's hashed ofc haha
i
seems like a reasonable enough approach. another would be to isolate just user id, username/email & password in its own table if it felt like enough of a security concern
Hey you never know man XD
excuse me, man's best friend
d
Yeah, that sounds good. I do think that something like this could be much nicer to work with tho.
i
Ah like private fields. Neat idea, you should check if there's a feature request for it yet, and if not make it!
d
Sure!
a
Hey there 👋 , Separating sensitive info into a separate model is a pretty common practice, so you could definitely go that way. We do have an outstanding feature request that would alleviate this situation and there is quite a bit of discussion in the comments if you’re interested.
d
Seems like a cool feature @Austin, but I think being able to have some fields excluded by default could also be super useful!
a
We have had other requests for that specific feature, but we have closed them in favor of having this one central issue. We still have not decided on a specific implementation though, and will consider a variety of use cases once we start on a solution.
d
I have a request for the feature ready, should I not post it then? The exclude feature would be extremely useful, but having the option of having fields excluded by default on the schema level would also be super useful. Why omit/exclude a field everytime when you can just include it a few times when needed?
a
I would not post it since we have closed other similar issues in the past. We still might implement the exclusion of fields by default at the schema level, we just haven’t decided yet and will centralize any discussion in this single issue.
d
Alright, won't post it. But yeah, would be super useful! Looking forward to it! Until then, I'll separate sensitive information in a separate model. Thanks for the help! The talk was very informative 😄
🚀 1