-
Notifications
You must be signed in to change notification settings - Fork 47
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
Gel sqla #536
Conversation
0885a10
to
fd5217c
Compare
Could you post some generated code? |
8c0f82e
to
aa57a94
Compare
6aa78ae
to
61c9c75
Compare
Create separate intermediate objects to represent links with link properties (because ORMs tend to view them as such). Don't allow crazy names (not usual type of identifiers). Multi properties behave more like plain multi links than anything else (because they have a separate table with the property value in it), so they should be reflected like that establishing a relationship. Reflect Gel modules into Python modules. Add tests that setup a Gel database and then generate the SQLAlchemy models from it. The individual tests use a SQLAlchemy session to access the database using postgres protocol.
for bklinks in bk.values(): | ||
if len(bklinks) > 1: | ||
# We have a collision, so each backlink in it must now be | ||
# disambiguated. | ||
for link in bklinks: | ||
origsrc = get_sql_name(link['target']['name']) | ||
lname = link['name'] | ||
link['name'] = f'{lname}_from_{origsrc}' | ||
# Also update the original source of the link with the | ||
# special backlink name. | ||
source = type_map[link['target']['name']] | ||
fwname = lname.replace('backlink_via_', '', 1) | ||
link['fwname'] = fwname | ||
source['backlink_renames'][fwname] = link['name'] |
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.
Could we always generate the disambiguated backlink, and then only generate the short name when it is unambiguous, or does that not work?
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.
We mostly expect not too many collisions so I tend to treat that as a the default. Backlink collisions appear when everything is linked to everything, which is not necessarily a common schema since that creates a lot of links to maintain.
Also, detecting unambiguous backlinks is a little more annoying that the other way around. Collisions are shown by identical names, but unambiguous long names would have to be checked by looking up their corresponding forward link name, seems more roundabout.
# have psycopg2 installed, as long as we run this in the test | ||
# environments that have this, it is fine since we're not expecting | ||
# different functionality based on flavours of psycopg2. | ||
if importlib.util.find_spec("psycopg2") is None: |
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 think it would be cleaner to do
try:
import psychopg2
except ImportError:
# handle it
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 wanted to avoid the import since I don't even need anything from psycopg2
directly, not using it anywhere myself. Didn't want to leave the impression that I needed the import myself and if it's not used, maybe it's OK to "remove this dependency check" making it look like an outdated comment or dead code. importlib
seemed like a more overt and unambiguous check.
Run `gel-orm --help` for more details.
More tests coming...