Fork me on GitHub

Question regarding persisting namespaced attributes: from what I can tell, as a general rule in clojure/java, you want to namespace your project with something that is globally unique - for example a domain name that you own. In the case of a large corporation that has multiple products, that would probably translate to root namespace of something like com.example.super-cool-product . Given that, I have several questions: 1. When a product (or even a company) changes its name, are the corresponding namespaces updated in the codebase? If so, are there refactoring tools that perform the operation safely across what could be a very large codebase? 2. Moving namespaces in code is relatively easy - but if said namespaced attributes are persisted in a database (say xtdb), then it seems to me that you'd need to run some kind of migration on the data. For very large datasets this could be pretty expensive yes? 3. I'm guessing any attributes that use the ::automatically-namedspaced-attribute syntax would need to be double-checked to ensure that they are now pointing to the correct name? 4. Is it even best practice to use these (really long) namespaced attributes when persisting data? I like the idea of using general (not company-specific) attributes as much as possible - for example, :person/given-name , :product/name , etc - because it makes looking at the data much less verbose. For example isn't it much nicer to work with {:some-entity/attribute "foo"} instead of {:com.example.super-cool-product.some-entity/attribute "foo"} ?


would certainly be interested to hear others' experiences with this one 🙂 personally, I've worked on a couple of big renames - we had the Crux -> XTDB rename last year (for trademark reasons :face_with_rolling_eyes:), and (before JUXT) I worked for a startup that changed its name 3 years in for marketing reasons (also :face_with_rolling_eyes:). to your questions: 1. we didn't at the startup, because it was closed source and considered too much churn to do so; we did with XT because of the trademark issues, and that it's an open source codebase 2. yes, XT still uses the name crux in serialised data, for the reasons you specified 🙂 we have mapping layers in and out of serialised data which increases the complexity there, but we considered this the lesser of the two evils 3. heh, absolutely 😅 4. yeah, I do tend to do stick to shorter (Clojure) namespaces when the (domain) namespace is unambiguous - if you're realistically only ever going to have one interpretation of 'product'/'person' in your system it seems a pragmatic call.

👍 2

re: (4), the consensus when I asked something similar in #fulcro was that it's fine to use "short" attrs (`:person/name`) if your data will not be flowing to "other" systems, e.g. if you're building a self-contained CRUD app. If that doesn't hold though, you need to worry about whether :person/name will be informative and robust enough, and it might not be

👍 1

Whether namespace qualified keys should be globally unique or not depends on what you need, I think. Unique within your org might suffice, like :product7/thing5. (depends, depends)


Awesome. Thanks for the responses. I get conflicted between being pragmatic vs "best practice" especially when it comes to stateful stuff like databases. 🙂


FWIW, at work we tend to use qualifiers like :wsbilling/* and :wsmessaging/* because those are "unique enough" and identify the context (World Singles Billing, World Singles Messaging, etc). But we also use unqualified names where context doesn't matter and fully-qualified (namespace) names where we want something more unique (or just opaque to the rest of the world).

👍 3

If you're storing those names anywhere persistently, you have to consider what actions you might need to take if you ever decide to change them. In the past, we've often done migration-on-demand to rename things or move them to different tables / collections / databases etc. It adds complexity but it avoids a massive stop-the-world rename/move. The approach also depends on whether your apps are the only ones accessing that stored data. In larger companies, there can often be multiple departments accessing shared data stores -- and different IT teams involved -- so migration-on-demand isn't always practical.

💯 1

Very helpful advice and insight. Thanks!