IME it results in much less context clutter from your test output.
96 karma · joined January 5, 2011
YC Badge: 0x7e5e706bf50eaa8c0d2993d4ec89a51e91cbbeab
IME it results in much less context clutter from your test output.
https://chat.openai.com/share/26792685-2790-4560-9f8d-9524de...
edit: Just noticed the shared version reports May 26, but this conversation was from January.
Initially I thought it would just be a fun thing, but I've realized there could be some value to the larger LLM community. Also I think it would be interesting to apply this format to experts in other fields.
Appreciate any feedback.
I'm curious, did you track metrics past AHI and how rested you felt the next day?
Similar issues with people-sourced explanations I suppose!
It was built on a single table that held the entity-attribute-value tuple along with some additional metadata like type information, whether or not the attribute was a pointer to another entity, and the cardinality of that relationship (one or many).
Relationships were walked via self joins and the eav columns were all indexed.
> EAV is often an anti-pattern when a schema could be defined
Super interesting, I wasn't aware that EAV is an anti-pattern in that case. Is it an efficiency thing?
For clarity, my design wasn't schemaless, values (can) have defined datatypes and relationships are first-class. I meant that I found adding to or modifying the schema was less cumbersome and error prone than traditional SQL schema additions or changes. I feel like SQL schema management is more suited to server-based dbs where you have tight control over the db lifecycle, which you don't when it lives on a bunch of mobile devices.
Totally agree with the ease of sync and conflict resolution, another strong pro.
Love to hear more about your approach! Also feel free to reach out (email in bio) if you'd like to compare notes some time.
Pros: querying complex data hierarchies was easy, and was able to skip the pain typically associated with managing a SQL schema.
Love to hear more about this.
My approach has been to convert errors into data and have behavior that deals with conveying these errors in different ways, but it's always felt too complex for the task. I've just got a lot of stuff dealing with handling errors in the different environments (jvm / browser / nodejs / rn) and across async and non-async code.
Like you, I was looking for a cljs wrapper for these things, but ended up not needing them in the end. The js interop ended up being pretty straightforward.
Happy to chat further, email in bio.