wundram / kahooba Goto Github PK

Pick a database system that can store the version document objects we want, and support a good query system. We also want something that will work well with a .net C# based server.

Fill in wiki page

https://github.com/wundram/kahooba/wiki/Complex-Relationships

Outline what the app is, what it does, what need does it fill, how does it work.

Fill in page on wiki

https://github.com/wundram/kahooba/wiki/SQL-or-NoSQL

We have to design the data model for the app.

• We need to determine what our object types are.
• How we are modeling relationships
• How we index the objects, and what their unique IDs look like
• How do we model complex relationships
• How do the relationships between the branch objects and version objects work?
• How do labels work?

Login

• Pick a technology
• Can we integrate with other auth systems like Crowd or AD? How about SSO?

Entitlement

• How do store entitlements
• Do roles sit between users and entitlements?
• How do we store entitlements? How do they fit with the data?
• How do we model special entitlements for authors and creators. (like the author of a comment can delete it, but not everyone who can author a comment)

Notifications

• How to assign notifications to roles, special roles (author, watcher, revisor, creator), and users
• How to map events to notifications subscriptions
• Some notifications are owned by the user, some by the project. How do we store them? How user overrides for project level notifications?

Profile

• What else is in the user record?
• Do we need groups?

Design the external API for the application

Not all users are going to want a dotted quad version syntax, and even with dotted quads, the last or second to the last might be a build, which could be very large, a date, or whatever. So you should be able to customize a version schema, or pick a built in one. Each schema is going to have a list of fields, each with a type like int (8,16,32,64 bits), string, date time, character...

Also each version schema has at least one format specifier to convert the fields into a string (and possibly read a string into fields). A parable format is one that can be parsed from a string into individual fields, and can roundtrip (ignoring decorative fields). A tokenizer or regular expression of some kind would need to be provided. One format would have to be canonical and parsable, and be in order of rank. This is the format that would be used in wildcard expressions.

The fields will have some attributes, like

• decorative: doesn't participate in comparisons or indices,
• rank: where does the field sit in the hierarchy. For example in major.minor.fix.build, major is rank 1, minor rank 2, fix rank 3, and build rank 4. In general version formats should lay out fields in order of rank, but there may be exceptions. The rank should probably be used in constructing a index for the version schema.