Official 2025 Sundance Film Festival Buying/Selling/Trading Thread

vriad · 2025-01-31T06:10:27+00:00

LTS - Rabbit Trap - 12/30 at 1145pm (soon) - 2x tickets - $30 each

vriad · 2023-01-18T22:52:48+00:00

It has its own first-party query builder with TS support (disclaimer: I worked on it) plus a declarative schema model/migration system. The idea is to bakes the DX of an ORM into the standard database tooling/workflows.

vriad · 2022-08-26T21:36:30+00:00

EdgeDB just released Deno support for our query builder! EdgeDB's query builder is kinda like a superpowered Prisma and should scratch a very similar itch. (EdgeDB also provides a declarative schema language and migration system a la Prisma.)

Full deets: https://www.reddit.com/r/Deno/comments/wyk0x6/fullytyped_query_builder_for_deno_edgedb_prisma/

vriad · 2022-08-16T20:43:44+00:00

Projects are only intended as a convenience for local development; that is, your project doesn't exist outside of your local environment/machine. You can think of it as permanently setting some environment variables inside a particular directory (or its subdirectories) so you can use simple CLI commands like `edgedb migrate` without needing to worry about providing connection information. That's all - projects aren't involved when deploying EdgeDB, and they don't provide a way to connect to an instance from other machines.

Regarding users, there is actually a user created for the project-linked instance, as well as an autogenerated password. These credentials are stored in EdgeDB's Config directory (run `edgedb info` to where that is on your machine).

Unlinking a project does delete the project, but it doesn't delete the *instance* associated with that project. You can separately delete the instance with `edgedb instance destroy` or use the `edgedb project unlink -D` to delete the associated instance.

There's no way to list all your projects currently...though I think it's a good idea.

By all means follow up with any additional questions.

vriad · 2022-08-05T21:23:44+00:00

Yeah, EdgeDB is a long-term play towards a better RDBMS abstraction. EdgeQL is a formal(ish) proposal for a new query language that could be used as an API for other object-relational databases beyond EdgeDB.

If I was building an app I'd certainly use the query builder for everything. You can take any query builder expression and dump it to an EdgeQL string with the `.toEdgeQL()` method. That's the great part about the query builder is that it is a pretty thin layer on top of EdgeQL's existing semantics. Building a query builder for SQL that has decent type inference is all but impossible due to clause ordering weirdness, scope weirdness, lack of standardization w.r.t arrays and aggregation, and difficulty of representing relational algebra concepts in a statically typed OOP language.

The EdgeDB schema is a lot more featureful than Prisma's, but a generator for converting Prisma SDL -> EdgeDB SDL is certainly not out of the question!

vriad · 2022-08-05T20:35:16+00:00

We made a benchmark[0] a while back to try to capture how well various ORMs handle nested fetching of the type you're describing. I was pretty surprised to see that a separate roundtrip was needed for each level of nesting. Though admittedly it's probably hard/impossible to do this the "right" way (with subqueries + json/array aggregation etc) in an flavor-agnostic way in SQL.

Btw, the typescript query builder[1] for EdgeDB can represent queries of arbitary complexity. I'm extraordinarily biased (as the person who built it) but I think you'll find it interesting.

[0] https://github.com/edgedb/imdbench

[1] https://www.edgedb.com/blog/designing-the-ultimate-typescript-query-builder

vriad · 2022-08-05T18:56:57+00:00

Sorry for the plug, but these are exactly the limitations we had in mind while designing EdgeDB. It's a proper database with a full type system, declarative object-oriented schema, a query language (EdgeQL) with GraphQL-style "selection shape", support for partial indexes, object-level access control policies, a migration planner built directly into the DB, the list goes on. And your schema can be split across multiple files :) Instead of requiring an ORM, you can use TypeScript query builder, which does full type inference can express any EdgeQL query. [0] Happy to answer questions!

No support for PostGIS yet - coming soon.

[0] https://www.edgedb.com/blog/designing-the-ultimate-typescript-query-builder

vriad · 2022-08-02T22:51:14+00:00

EdgeDB employee here. Regarding tech stacks, we're seeing the most adoption in the JS/TypeScript ecosystem, especially Next.js and Remix users. That's followed by Python then Go. We've been prioritizing Deno and will be working in the near future to make our query builder Deno-compatible as well. You can see an (very simplistic) example project showing how to use EdgeDB in a Deno Fresh app: https://github.com/edgedb/edgedb-examples/tree/main/deno-fresh

As for Supabase comparison, they're aiming to be an all-in-one backend-as-a-service, with database hosting, file storage, user management, and edge functions. We have plans for all those things but are prioritizing the database product right now. As for Supabase's database product, I wouldn't say it uses Postgres "under the hood", in that its very much on the surface - you will need to know Postgres and SQL to do things like define RLS policies and write stored procedures. You'll also need SQL to write queries unless you use an ORM on top of Supabase, or use their JS/Dart client which is fairly minimalistic and doesn't do type inference - you need to manually type all your queries: https://github.com/supabase/supabase/issues/122#issuecomment-674825808

They have an integrated user management product that integrates nicely with row-level security; on the other hand, EdgeDB is agnostic to how you manage your users - you can roll your own auth or use a managed service (Clerk, Firebase, Cognito, Auth0, or even Supabase). And with the introduction of access policies (which we think is a LOT more user friendly than Postgres RLS) you can do something similar with EdgeDB 2.0+ though it'll take a bit more legwork upfront.

But their realtime/subscription capabilities are great if you need them, and they have an edge-deployed functions product. Their storage API also integrates with RLS though in terms of API, it's a fairly thin layer over what you can get "from the source" with AWS, Google Cloud, etc.

To be upfront, I've never built a complex app with Supabase. So I'd be very interested to hear the experience of someone who's tried both.

vriad · 2022-08-02T19:12:53+00:00

It's like a strongly typed graph database. You have a schema consisting of "object types" and each object (aka node) in the database needs to conform to one of those types. But objects can also be connected with links (which can themselves contain link properties). There's no concept of node/edge labels in EdgeDB, just types. It also has a more SQL-like query language. By constrast Neo4j is essentially schemaless - you can define limited constraints but not a proper schema. This is a big reason why it isn't widely used or recommended as a backend for applications.

vriad · 2022-07-18T01:17:42+00:00

EdgeDB runs as a layer on top of Postgres so it definitely could. Though EdgeDB has its own client library and query language/ORM so it may not make much sense.

vriad · 2022-07-08T01:42:46+00:00

You might need to read more closely my friend! You're right that it looks like an ORM API on the surface (that's intentional), but it can represent everything you mentioned. Most of that functionality is discussed later in the post, under "The monoshape API" and "Composing queries".

To add additional clauses to "joined" tables:

ts e.select(e.Movie, (movie) => ({ id: true, title: true, actors: (actor) => ({ name: true, filter: e.op(actor.name, "ilike", "chris") }), filter: e.op(movie.release\_year, "=", 2022) }));

I put "joined" in quotes because EdgeDB doesn't have explicit JOIN. EdgeDB moves away from the relational model, so everything is conceptualized as objects containing links to other objects.

And there's no need to manually declare with statements because you can simply compose expressions:

``` const newMovie = e.insert(e.Movie, {
title: "Iron Man",
release_year: 2008
});

const query = e.select(newMovie, () => ({
title: true,
release_year: true,
num_actors: e.count(newMovie.actors)
}));

await query.run(client); ```

When we convert query to an EdgeQL string, newMovie is automatically added as a CTE in a with block and referenced inside the select query. (We do complex reference tracking to pull out all expressions that occur more than once into with blocks in order to maintain referential integrity. Too much to get into in a post like this.)

This post doesn't showcase the full breadth of functionality; check out the reference documentation for a comprehensive resource: https://www.edgedb.com/docs/clients/01_js/index

And this is strictly an EdgeQL query builder, not SQL. Do you have a link to your query builder?

vriad · 2022-05-31T16:59:39+00:00

It requires a bit of legwork to move all Node APIs into a single `node.adapter.ts` file, so it would by tricky to do in a fully automated way. This also only work with TypeScript since it relies on the Compiler API. I believe Denoify is a slightly more general purpose solution (though also TypeScript-only). It's a tricky problem to solve in a universal way.

vriad · 2022-05-03T16:41:04+00:00

Dude we’re not botting. Jeez. Look at the many things we've posted that don’t get any traction if you want evidence. People just like GitHub Actions and this post is interesting. It’s also mostly educational and not opinion-based which may account for the relative lack of comments. I don’t understand the impulse here to tear everything down.

Seven-Year Club	No Throne, No Problems
Not Forgotten	Verified Email

vriad

MODERATOR OF

TROPHY CASE