-
Notifications
You must be signed in to change notification settings - Fork 222
feat(data-modeling): integrate diagramming package COMPASS-9357 #6979
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
…nto diagramming
i have no idea what exploded lock file |
source: source.ns, | ||
target: target.ns, | ||
markerStart: 'one', | ||
markerEnd: 'many', |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this a placeholder item?
Something that's become fairly clear over time is that we're likely going to want to work with concrete cardinalities if we can (i.e. number ranges rather than one
or many
)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, actually it needs to be like that. I'll change this to reflect the store cardinalities. My assumption is that we will be having 1 or 2 as numeric representation for one and many respectively.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So ... what we'll ultimately have is descriptions like "1 to 4–6" or something along those lines, at least if we ultimately want to give schema recommendations (still a goal for Compass to have that eventually), because it's become pretty clear that the numeric values of the relative cardinality ranges matter for those (you maybe be able to create an embedding of collections in a 1:5 case but not in a 1:200 case)
? 'Unknown' | ||
: typeof field.bsonType === 'string' | ||
? field.bsonType | ||
: field.bsonType[0]; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This line is also some sort of TODO?
Looking through it, it mostly seems to be additions of genuine new dependencies? |
package-lock.json
Outdated
"configs/eslint-config-compass/node_modules/eslint": { | ||
"version": "8.57.1", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Seems like something went really wrong when you installed a new dep, you now have two versions of eslint in package-lock, one of them is not matchin the required one. This is partially why package-lock blew up so much and why CI is failing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, i finally resolved this, thank you. I tried checking out lock file from main couple of times and was not sure what I am missing. Eventually from your other comment realized its origin
that I am missing.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you try running
git checkout origin/main -- package-lock.json
npm install
on your branch? This gives a pretty different result for package-lock at least on my machine (without eslint being messed up)
// to React 18, but for the time being we will just resolve react to | ||
// actual files ourselves to work around that | ||
'react/jsx-runtime': require.resolve('react/jsx-runtime'), | ||
react: require.resolve('react'), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Probably should add this to ignore in depcheckrc file, we do this already for another package that we just need to resolve
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
done in bba2841
title={diagramLabel} | ||
edges={edges} | ||
nodes={nodes} | ||
onEdgeClick={(evt, edge) => { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think we'll be doing removal like this, but it's actually neat for now :)
Description
Checklist
Motivation and Context
Open Questions
Dependents
Types of changes