deobald
Joined 17 years ago
Karma
65
Submissions
52
Member since
Dec 14
Recent submissions
Comment · 2 years ago
Thanks for this! I'd like to drop a note of explanation here, for future readers:
Yes, anyone can "just create a LinkedIn account." However, quite a few people across the globe are trying to decrease their online surface area. While many of us (myself included) just have a password manager filled with thousands of entries and 32-character passwords, some folks are not comfortable living that way. I also find myself unsubscribing from or filtering emails from these services at least once a day, so I can appreciate why many folks are increasingly trying to simplify their lives by eliminating SaaS logins.
Even without creating a LinkedIn account, one could fill in a dummy URL to satisfy the JavaScript validation and submit the application. However, we chose not to do this because of how the YC application itself is structured. The submission requirements are intentionally strict (60 second founder video, <3mins demo, very specific questions, etc.) and subverting the application process feels antithetical.
Having the option to opt out of the LinkedIn field is greatly appreciated.
Comment · 2 years ago
We did try to get WASI to work, but ECL itself doesn't yet target it. It fell down on missing set/longjmp support in wasi-libc. We haven't tried WASIX yet.
There are other approaches than the one we've taken so far, and we're still experimenting. But for the current demo, we're quite happy with Emscripten. The entire Wasm ecosystem feels pretty darn magical. :)
Comment · 2 years ago
Endatabas team here. Thanks for clarifying why this post was marked as a dupe.
We recently released our Beta, including a live in-browser demo built on Wasm. It seems the OP noticed our release somewhere, but didn't mention the Beta or the Wasm build in their new post.
Take care, -steven
Comment · 2 years ago
This is really handy and, frankly, less confusing than doing all of this with GUI tools on MacOS. ;) Thanks for publishing this!
Comment · 2 years ago
As mentioned in another branch, I took a stab at writing up a "What?" page to pair with the "Why?" page: https://docs.endatabas.com/appendix/what.html
It tries to be less wordy. :)
Same as above, I'd love your feedback, if you have any. Our Discord is on the homepage, if that's easier than email.
Comment · 2 years ago
I took a stab at writing up a "What?" page to pair with this: https://docs.endatabas.com/appendix/what.html
It tries to be more concise. :) Would love your feedback, if you have any. Our Discord is on the homepage, if that's easier than email.
Comment · 2 years ago
I think the documentation you're looking for is here:
https://docs.endatabas.com/sql/path_navigation.html
I've just pushed a change mentioning that paths can be used in both SELECT and WHERE clauses. Sorry for the ambiguity.
For example:
`select * from stores where addresses[0].city = 'New Jersey';`
...can be used on the demo data, found here:
https://www.youtube.com/watch?v=oDHGjUMqPvI&t=140s - demo
https://github.com/endatabas/marketing/tree/main/2023-09-dem... - code
HTH!
Comment · 2 years ago
txtai looks cool! It's not obvious from the title of the post, but Endatabas isn't really comparable to SQLite in this way. Endb is a cloud-native columnar immutable database with separated storage and compute. Only the SQL grammar is SQLite-inspired.
That said, the significant dialect difference is that Endb's JSON-like documents are strongly-typed. One of the places the Endb SQL dialect diverges from SQLite's is typing. In this respect, SQLite is "more schemaless"... at least at the level of weakly-typed scalars and nested JSON (since JSON supports a diminutive set of types).
Endb's data types, their exposed JSON-LD types, and internals: https://docs.endatabas.com/reference/data_types.html
Endb's SQL data types: https://docs.endatabas.com/sql/data_types.html
...all of these can be used at any nesting level, which makes nested data in Endb quite different from JSON.
Hope that helps explain the difference!
(I'm involved in the Endatabas project and happy to answer other questions or clarify this.)
Comment · 2 years ago
While acknowledging you're only addressing the Copeland paper (and not Endatabas, where the OP found it), here's the Endatabas solution to this problem:
https://www.youtube.com/watch?v=oDHGjUMqPvI&t=129s
Apologies for the hijack. :)
Comment · 2 years ago
I'm involved in the project.
The temporal columns are intrinsic to Endb, but they are completely optional. By default, Endb queries run as-of-now, which then return the same results one would expect from a regular Postgres database.
Postgres temporal tables can't make Postgres natively aware of time, so temporal queries tend to be awkward, even if you want the default as-of-now result.
There are temporally-aware databases (SAP HANA, MySQL, SQL Server), but they all treat time as an additional concept layered on top of SQL-92 via SQL:2011. It's difficult for a mutable database to assume immutability or a timeline without becoming another product.
`entity_history` and similar audit tables aren't comparable at all, since they don't even involve the same entity/table, which means all querying of history is manual. Indexing of audit tables is at least a bit easier than the SQL:2011 temporal solutions mentioned above, though.
In all these cases, schema is still an issue that needs to be resolved somehow, since (again) incumbent relational databases assume a Schema First approach to table layout. Endb is Schema Last and allows strongly-typed nested data by default.
The Endb demo is pretty recent, and explains all of this in more detail, with examples:
Socials: - bsky.app/profile/deobald.bsky.social - github.com/deobald - mastodon:https://fantastic.earth/@deobald - https://www.deobald.ca
---
- https://www.deobald.ca - https://fantastic.earth/@deobald