Coder Social home page Coder Social logo

Comments (5)

jmalloc avatar jmalloc commented on August 22, 2024 2

I think we probably want to have a hard minimum that engines should support, and then recommended maximums for application developers.

from dogma.

jmalloc avatar jmalloc commented on August 22, 2024

We need to come up with lengths that we're comfortable adding to the spec. Just to get the ball rolling ...

message descriptions

I don't think there's any obvious length here, but given that they're intended to be written to a log we'd generally want them to fit in a "single line", however long that may be. Perhaps we could suggest that they SHOULD be a maximum of 120 characters. We'll probably truncate them when storing in the database, but I'm not sure if that's really relevant to the spec at all. We could say that the engine MAY truncate or compact the messages for display purposes.

identity keys

We already suggest that the keys be UUIDs, and I can't really think of a strong use case for using anything other than a UUID, so we could even consider mandating that keys MUST be a UUID. Short of that I'd probably make the limit here the same as for aggregate/process instance IDs just for consistency/ease.

identity names

These should probably be treated a bit like type names in an arbitrary language - long enough to be descriptive, but not so long as to become unwieldy. We might want to suggest that they SHOULD be <50 characters or so, but require engines to support more. In practice these could be truncated and not impact engine operation (since it's the key that is definitive) but I am disinclined to allow for such truncation since they are still an identifier.

aggregate & process instance IDs

We definitely want to at least allow for UUIDs, but also have the "compound" keys that we construct from multiple other UUIDs, so we want to allow for fairly long identifiers, however, the longer we allow the bigger and "slower" database indexes become in engines like Verity. I'm inclined to cap this one at something like 128 bytes - plenty long enough for a few UUIDs, etc, chained together, but still shorter than an average SQL database's VARCHAR column width.

from dogma.

danilvpetrov avatar danilvpetrov commented on August 22, 2024

I don't see any reasons not to specify those limits. Should those limits should be presented as recommendations for engine implementations or as hard requirements?

from dogma.

koden-km avatar koden-km commented on August 22, 2024

Your suggested limits seem fine. I like the idea of recommended limits without them being hard limits. That allows users to still do what they need but guides them to the intended usage.

from dogma.

jmalloc avatar jmalloc commented on August 22, 2024
  • As of Dogma v0.12.0 identity keys must be RFC 4122 UUIDs.
  • As of Dogma v0.12.1 identity names must be between 1 and 255 bytes in length

from dogma.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.