Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

MySQL for Developers

planetscale.com

Post reply on HN
Print view View original

111–119 of 119 posts

Re: MySQL for Developers

#111

Post by aarondf »

reactordev wrote: post #84
aarondf wrote: post #2

Hey HN, I made this course :D The course is a bit more than 7 hours long split over 64 videos. I was always frustrated by the lack of intermediate database content, it seemed like it was mostly intro stuff, or straight to DBA level. So I read as many database books as I could, read through the official docs, and made this course specifically for application developers. If yall have any feedback I'd love to hear it. I…

I’ve been using MySQL since 1998. I know the source code very well. I’ve designed large platforms with MySQL but I run postgres in production. I also wrote my own SQL engine. This is very VERY well done. Kudos. I’m loving that we have a contender for mongo atlas with planetscale. Keep this kind of content coming and you’ll be the next snowflake.

Well that's a massive encouragement. Thank you so much!

Re: MySQL for Developers

#112

Post by aarondf »

kbumsik wrote: post #97

I really wanted to use Planetscale, but there are two blockers: - No foreign key support - No CTE support I tried using Planetscale knowing that there is no foreign key support because it is fine to me. But I had to stop using Planetscale because of the second. My ORM (ent for golang) relies on CTE so I simply cannot run complicated queries. So if you are considering Planetscale, test it enough especially if you are…

We do support foreign keys, just not foreign key constraints. There's actually a video in the course that talks about the difference and why you might not need constraints: https://planetscale.com/courses/mysql-for-developers/indexes....

Correct that we don't yet support CTEs. I'm surprised to hear of an ORM that relies on them! That's pretty cool, never heard of that.

Re: MySQL for Developers

#113

Post by aarondf »

Implicated wrote: post #95

As someone who has been passively watching you develop and promote this course over what feels like _forever_ - I'm SO excited to see the feedback here the way that it is. Kudos to you and the team at Planetscale, Aaron.

Thank you very much. It has certainly been a long journey, and the positive feedback here is a massive relief.

Re: MySQL for Developers

#114

Post by aarondf »

heybrendan wrote: post #90

Hi @aarondf, this is bloody phenomenal! Fantastic work. Can we eventually expect something similar for PostgreSQL [for Developers]? And does this course include ORM's, like SQLAlchemy?

I won't be the one to do PostgreSQL for Developers, but I think _someone_ should!

I think a good teacher could make a lot of money doing it if they wanted.

This course talks briefly about ORMs, but does not go into usage of any particular one. All raw sql!

Re: MySQL for Developers

#115

Post by aarondf »

whoiscroberts wrote: post #93

Is this course relevant for MariaDB as well?

I'd say some of it is, but I don't know enough about Maria to say much more than that. MySQL and Maria have diverged quite a bit at this point, so I'd proceed with caution on any of the specifics.

Re: MySQL for Developers

#116

Post by collinmanderson »

geekodour wrote: post #20
aarondf wrote: post #13

Earlier quoted context omitted.

Whew, that's a relief. Keep me posted if you find out it's on our side.

okay totally on my side: it was uMatrix :) https://github.com/gorhill/uMatrix/wiki/Per-scope-switches#r...

Yeah Vimeo often requires a referrer header to be sent to prevent embedding the video on other websites.

Re: MySQL for Developers

#117

Post by tbarn »

kbumsik wrote: post #97

I really wanted to use Planetscale, but there are two blockers: - No foreign key support - No CTE support I tried using Planetscale knowing that there is no foreign key support because it is fine to me. But I had to stop using Planetscale because of the second. My ORM (ent for golang) relies on CTE so I simply cannot run complicated queries. So if you are considering Planetscale, test it enough especially if you are…

I'd need to dig into the code, but it looks like someone has used PlanetScale with ent before: https://betterprogramming.pub/how-to-connect-ent-to-planetsc...

Did you follow that blog post already?

Re: MySQL for Developers

#118

Post by melvinmelih »

KronisLV wrote: post #108
melvinmelih wrote: post #101

Earlier quoted context omitted.

> where you want to store some amount of logic in the database itself If you’ve ever worked on a decently sized project, you’ll quickly realize this is an anti-pattern that you should avoid at all cost. Imagine having multiple teams updating that logic without any version control or visibility in what’s stored in pg.

> If you’ve ever worked on a decently sized project, you’ll quickly realize this is an anti-pattern that you should avoid at all cost. Not sure about this. On one hand, packages of reusable logic in the DB can be useful - like processing some data when you're selecting it, or doing common validations before inserting data, or even when trying to do some batch processing or reporting. On the other hand, I've worked on…

> Even with version controlled migrations, it was an absolute mess to work with, to debug and extend, even though the performance was great.

This is exactly what I mean. Sure, anything is technically possible, I’m not saying that you can’t version your stored procedures (even though even that has almost never been the norm on any team I’ve worked on). But is it the ideal setup for your team/project? Far from it.

Re: MySQL for Developers

#119

Post by kbumsik »

tbarn wrote: post #117
kbumsik wrote: post #97

I really wanted to use Planetscale, but there are two blockers: - No foreign key support - No CTE support I tried using Planetscale knowing that there is no foreign key support because it is fine to me. But I had to stop using Planetscale because of the second. My ORM (ent for golang) relies on CTE so I simply cannot run complicated queries. So if you are considering Planetscale, test it enough especially if you are…

I'd need to dig into the code, but it looks like someone has used PlanetScale with ent before: https://betterprogramming.pub/how-to-connect-ent-to-planetsc... Did you follow that blog post already?

I just read this post, it looks like a demo for basic operations.

When I tried it at the end of the last year, ent works fine with Planetscale for basic reads. However, it fails to read when I use complex queries with Ent GraphQL integration.

ent added quite a lot of features last year so things might changed from the time when the blog post was written.

Post reply on HN