How do you want to make money? Do you want to implement autoscale solution or how ?, this sounds increadibly in quite stagnate environment, good look I will give it a try
Show HN: EdgeDB 1.0
251–260 of 332 posts
Re: Show HN: EdgeDB 1.0
#252Earlier quoted context omitted.
What a terrible attitude to have, that's truly the worst possible interpretation. How's that dissing anything? They are saying they have a good abstraction that will make you more productive. While it might not be, this is literally what makes software the amazing tool it is, building layers of abstraction that make you more productive. You seem to have gotten it all wrong, how could building something on top of SQL…
It's very frustrating that whenever a team is showing something new they've built to HN, so many of the top comments are focused some incredibly nitpicky, personal issue that somehow negates everything else about the project. It's an amazingly lazy and inconsiderate way to respond to people who've put a bunch of effort into building something.
Agreed ! Usually when you look at these "haters" there is nothing of value in their "submission" sections under their profiles, which usually tells me exactly how to "read" the comment(insult).
Re: Show HN: EdgeDB 1.0
#253Hi. Is there architecture document explaining all moving parts ? And tracing what is happening from beginning of query to result?
Re: Show HN: EdgeDB 1.0
#254Won't the functional variant read better than the SQL dialect movie_reviews .filter(_.actor.name.lowercase() == "Zendaya") .groupBy(_.title, _.credit_order, avg(_.ratings)) .sortBy(_.credit_order) .take(5) vs. select Movie { title, rating := math::mean(.ratings.score) actors: { name } order by @credits_order limit 5, } filter "Zendaya" in .actors.name
Your query returns 5 rows total. The EdgeDB query returns all movies that Zendaya is in [1] and, along with each movie, the first 5 credited actors.
Also, it looks like your version also does implicit joins (like EdgeDB), but I'm not sure how they would work in that style.
[1] Or maybe only movies where Zendaya is in the first 5 credited actors; I'm not sure.
Re: Show HN: EdgeDB 1.0
#255Hi. Is there architecture document explaining all moving parts ? And tracing what is happening from beginning of query to result?
We don't have a doc on internal architecture, but we discussed it during our live-streamed launch event today: [1]
> And tracing what is happening from beginning of query to result?
EdgeDB exposes a Prometheus endpoint with a bunch of metrics. We don't have a public API for tracing individual queries yet.
Re: Show HN: EdgeDB 1.0
#256Re: Show HN: EdgeDB 1.0
#257This looks pretty cool. I'd be interested to hear when the Rust bindings will be production ready: https://github.com/edgedb/edgedb-rust
Re: Show HN: EdgeDB 1.0
#258I wonder how EdgeDB talks to postgres. Does it speak the Postgres protocol and translate the queries, or is it more of a deeper integration in to the storage layer?
Very interested in this! I've been wanting to build a generic HATEOAS server and this feels like this might be the right database!
Re: Show HN: EdgeDB 1.0
#259For this query to work which is shorter than SQL
select Movie { title, rating := math::mean(.ratings.score) actors: { name } order by @credits_order limit 5, } filter "Zendaya" in .actors.name
Do I need to write some metadata layer so this higher level query would know what's going on? Similar to LookerMl?
Re: Show HN: EdgeDB 1.0
#260Hell yeah. This is what I've wanted ever since I first learned about Apple's CoreData. This seems great. I have a highly interrelated data model (think parsed natural language text with annotations), and writing SQL to keep all of that data aligned and synced is a pain with an ORM. Am I right in imagining this works similarly to how Apple's CoreData does? It lets you build objects linked to each other but handles all…
I'm not too familiar with the CoreData API, but from a quick googling it seems like this is some sort of an ORM on top of SQLite. We position EdgeDB as a database server, not a library, partly because you can interact with it from different programming languages. But we design our client library with focus on API composability, check out our edgedb-js library for example: https://www.edgedb.com/docs/clients/01_js/ind…
Why position it as a database server if you could position it as something else, like an interface server? Just curious.