@U0DJ4T5U1 what are your goals with a group reading?

would love to get a feedback document or questions document if you find things difficult or confusing in the docs!

@UEFE6JWG4 i use datomic at work, so it pays to know how it works. and it's been my experience that I learn better when i have a chance to casually discuss something.

Cool, makes sense. I'd love to hang out with you for an hour or so while you do a read through if you'd like.

@UEFE6JWG4 awesome! Let me know when you have time. I'm poking at the docs right now for about idk, half an hour.

fyi this page has several broken links https://www.datomic.com/benefits.html I sent an email about the first i found.

I'll get that fixed, thanks for the heads up.

I'm also usually not online at the time you sent that message btw. Between 7am and 5pm eastern is best if you wanna hang out and review.

@UEFE6JWG4 what about tomorrow at 3 eastern (2 for me?) For a Datomic doc read through. :)

Your data model typically won’t change much. And when it does, you’re probably growing the schema as apposed to altering it. For this reason, IMO, I would say that repetition/DRY violations are more acceptable and less likely to create problems like it would for other applications. And I would prefer static schema definition over dynamically generated schema. My advice would be to avoid doing anything fancy and just define your schema in the boring, tedious and perhaps repetitive way. And only when you really start to feel pain and frustration that you begin looking to abstract. These are just my thoughts though, so I would see what other people think too.

i’m inclined that direction too, one giant EDN file with attr definitions

Yeah that’s pretty much how it looks in my use. Just a schema.edn file. I have tried fancier approaches many times and I always end up scrapping it in favor of a single statically defined schema.

the idea EAV / sparse matrices is a lot reuse of attributes, eg ‘phone number’ can be used for employees, customers and corporations, it’s not immediately obvious to see the patterns loooking at a giant list of attr definitions

This is another interesting one. It’s not discouraged to generalize attributes. I stand of com.example.employee/phone-number, you can do something like com.example/phone-number. And the same attribute can be used on multiple entities. Then systems consuming that attribute don’t need to know what entity the phone number is for. It can operate on it generically. And you can usually still derive the entity from other attributes like an employee ID or something

The namespace of the attribute doesn’t need to specifically define the entity. You would add context where it’s needed.

Ya exactly , my thinking is already headed this direction , good to hear it confirmed though

what namespace would you give phone number attr?

would i try to come up with abstract esoteric words that encapsulates a ‘employee, contractor, customer, or corp’ entity

eg ‘contactable’ 😂

It really depends on your use case. If you have one phone-number it could be namespaces to a contact or something. Maybe you have different types like mobile or home. Maybe you can have multiple mobiles. Maybe companies and people can have phone numbers. It’s hard to say. But you can always start with just what you need and improve it later. Try not to over engineer abstractions too early. Accept that your requirement will change and make sure your approach will support that change. Maybe now you start with a single :com.example/phone-number and when a situation comes up that you need to distinguish between a mobile and home phone number. You can make two brand new attributes for those two. Deprecate your old one and stop using it, and start implementing changes to your system to roll out the new one. Your old one will still work just fine, and all systems that haven’t been changed yet will continue to work. Renaming the attribute comes to mind as a solution, but doing so will break everything that refers to the old attribute. And you’ll have to make a potentially big refactor to update everything to use the new attributes. So in practice, continuing to support the old attribute while adding the new attributes can make rolling over much smoother. You can also add aliasing logic to your systems to convert between the old and new attributes. For example a system might ask for the old generic attribute, and it might be easier to simply return either one of the new attributes as apostles to refactoring that whole system.

There is a really good talk here. https://youtu.be/oyLBGkS5ICk

Particularly the chapters about growing and changing schema.

Thanks 🙏 , you personally just keep both new and old attributes around (?), meaning the pull requests try to find both right

i’ve seen it but i’ll rewatch

Yes. You would keep old attributes around. And support both. Basically we understand that we can never really know what the future will be, so we avoid making assumptions and trying to predict requirements until we know for sure (don’t abstract prematurely and only build what is needed). And because we haven’t tried to predict the future, we also understand that changes are inevitable. We will rarely get it right the first time. And doing massive rewrites and refactors suck. Supporting the new and the old means we don’t always have to refactor the old. We’re much less likely to break things that still use the old way. Instead of refactoring whole systems, we also have the option to alias the old attributes to new attributes. We can also convert between the versions. In general, this is the Clojure and Datomic way, however it’s important to also know that these are rules, and not guidelines. While there are good reasons to approach change in this way, there will always be situations where it’s completely valid to not follow this advice. Sometimes it is easier to just rewrite and replace.

An example of this in practice is in clojure spec1 and spec2. They didn’t refactor spec1, they just made a brand new lib on a completely different namespace. A clojure JDBC lib also does this.

Pathom2 vs Pathom3.

Ya , i like the clojure approach towards backwards compatibility, unfortunately our product direction could be better, it keeps changing , so hopefully our schema doesn’t become a mess, it’s going to be hard to use the rename feature anyways because we’re in distributed system and multi region so i can’t just stop the world to do a breaking schema change

Thanks 🙏 this really helped clarify some things

I’ve not really used the rename feature. But I have written layers to convert between new and old versions instead of refactoring. Good luck!