Closed hedder closed 9 years ago
Yep, unfortunately this point breaks the specification. It was easier for me to implement only uuid ids at the beginning, as they allow you to generate id for a new object in the front end.
But after a quick look at the code I can tell it is probably not that hard to implement id of any type. I add this feature to 1.0.0-alpha.3 milestone.
@jakubrohleder you are allowed to generate IDs in the spec. when you create new elements but not required to. This is why the spec allow strings - it can be anything.
I know it, once again the 'only uuid4' policy was introduced just to make writing of the first package version easier (I thought I will use 'local id generation' more often).
@jakubrohleder sorry if I misunderstood you - did not want to be rude or anything. btw @hedder and I are working on the same project.
@jsenecal no problem! I'm not native, so I'm not surprised that sometimes I can get misunderstood. I'm glad that you guys want to commit to this project and find it useful ;)
@hedder @jsenecal I pretty much fixed this issue. From now on you can use uuid4
, int
, string
or even custom id validator/generator.
Type of id field, currenty only uuid4 is supported.
However, according to official documentation: