Comments (3)
Overall I still think UUIDv6 is a good idea, I just haven't had a chance to work on it in a while. If it expires it can certainly be resubmitted. There are a lot of little pieces to the puzzle to get interest and agreement on in order for it to result in an actual RFC. One of the next steps is to fill out the README with more info on each of the points. In my past conversations on this there are many different ideas on how different aspects could be approached, some of them more workable than others. Documenting the various tradeoffs is an important part of putting together a complete UUID draft. I hope to be able to get back to this soon and any feedback or assistance on it is also welcome.
from uuid6-ietf-draft.
Thanks for response. I agree that it is important to document tradeoffs and alternative solutions.
However, I think that some of them are out of scope for UUID v6 standard. For example, length and text encoding specifications could be very useful, but are not really related specifically to UUID v6 standard because they could also be used with existing UUID versions. I don't know how RFCs are expected to be structured, but IMO this topics should be part of separate UUID RFC, or this draft should be renamed/moved to reflect what it does. But some other things should probably be part of this specific draft.
Also, one other thing that would be useful to document is performance difference/impact between old-school auto increments, existing UUID versions and UUID v6 for usage as primary keys in various databases, database relations and other storage applications, stored as just HEX text with dashes, in binary or other encodings.
from uuid6-ietf-draft.
Thanks and I get what you mean.
I do think the points you bring up are a good example of why an organized document is needed, clearly laying out what the current position/decision is as regards this RFC proposal on each point. For example, I see what you mean on the text encoding being a separate issue, but at the same time the existing RFC does specify both the binary layout and the text specs so there's precedent for that. And also with all of the effort required to actually make an RFC get published, I think it's important for it to contain everything that will solve the most common problems - i.e. IMO, the decision about if text formats should be included should be based on if it helps solve the real-world problems related to using UUIDs in the wild. And, while I'm not dead-set on this, the reason I included the text formats in the draft was because I thought it was important enough.
The performance data would definitely be interesting and useful to know. Someone would need to build out some benchmarks for that and it would be a welcome contribution for sure. There will certainly be some variations in this based on tradeoffs of how it's implemented. E.g. storing UUIDs in binary might be faster but then be more of a hassle for developers to deal with mangling them back and forth in SQL. This sort of concern is important to discuss and be aware of, but then it's impact on the final spec will probably something very simple e.g. "implementations can decide to store UUIDs internally in whatever format they want, the options are..."
I will try to carve out some more time to fill out the README of this repo with the data I have. Contributions are definitely welcome in the form of a PR that we can discuss and the hopefully merge.
from uuid6-ietf-draft.
Related Issues (20)
- The conditions for the use of source-generated UUIDs and receiver-generated UUIDs HOT 3
- Provide a complete UUIDv8 example
- Encouraging the use of UUID as the primary key HOT 8
- Fork safety HOT 1
- Fix RFC4086 link in Normative References
- Draft 04: MUST to SHOULD to reduce "absolute monotonicity" requirements
- Tout est Terrible. Endian problems with original RFC 4122 + case problems HOT 8
- Draft 05: B.2. Example of a UUIDv7 Value two "var" in table
- Draft 05: MUST veribage in Reliability of 6.1
- Announcement: Post-IETF 114 and the future of this Draft HOT 26
- Typo in UUIDv7 example value HOT 1
- Remove "time-based" constraint from version 8 UUID HOT 1
- Further clarify v7 field description HOT 3
- Required UUIDv7 generator features for RDBMS (PostgreSQL etc.)
- Approximate UUID timestamp calculations HOT 24
- Performance testing for UUIDv7 HOT 14
- RDBMS and other platforms that support UUIDv7
- UUIDv7 logo HOT 20
- Typo in Approximate UUID timestamp calculations HOT 13
- Reserving a special form within UUIDv10 (alternating UUID) HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
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.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from uuid6-ietf-draft.