Skip to content
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

Naming of columns #221

Closed
dantownsend opened this issue Sep 8, 2021 Discussed in #206 · 7 comments · Fixed by #288
Closed

Naming of columns #221

dantownsend opened this issue Sep 8, 2021 Discussed in #206 · 7 comments · Fixed by #288
Labels
enhancement New feature or request

Comments

@dantownsend
Copy link
Member

Discussed in #206

Allow Table columns to map to database columns with different names.

For example:

class MyTable(Table):
    name = Varchar(name="person_name")

In the example above, when doing queries, you will use MyTable.name, but the actual column in the database is called person_name.

This is useful when using Piccolo on legacy databases with non-ideal column names.

@dantownsend dantownsend added the enhancement New feature or request label Sep 8, 2021
@dantownsend dantownsend added this to To do in Enhancements via automation Sep 8, 2021
@gmos
Copy link
Contributor

gmos commented Oct 4, 2021

Would be nice to have this. I have an existing database with a column name called 'class'. So named the field 'class_' in the definition. But then obviously table accesses fail. So needed a workaround.

Already wanted to make a view in the database to change the offending name. But then looked into the code and found this workaround:

class LoraKey(Table, tablename="copy_lora_key", db=DB):
    # ...
    class_ = Varchar(null=False, length=1)

LoraKey.class_._meta._name = 'class'

Seems to do the job nicely, albeit a bit of a hack.

@gmos
Copy link
Contributor

gmos commented Oct 4, 2021

Seems to do the job nicely, albeit a bit of a hack.

Alas, while fetching and updating works, creating and initializing a new instance doesn't.

t1 = LoraKey( class_="A", other=42 )  # doesn't find the field and vs-code gives a warning
t2 = LoraKey( class="A", other=42 )   # obviously gives a syntax error.
# Need to do it in steps for this to work...
t3 = LoraKey( other=42 )
t3['class'] = "A"

@dantownsend
Copy link
Member Author

@gmos I had a quick go at fixing this issue - still need to write some more tests, but hopefully should be able to release it soon.

@dantownsend
Copy link
Member Author

dantownsend commented Oct 4, 2021

The most problematic thing is passing it into the constructor - so in your example LoraKey( class="A", other=42 ).

There's a related issue, where a dictionary of arguments can be passed in. This is one potential fix:

#268

I think it's cleaner than letting a user pass in either class or class_. I'll have a think.

Enhancements automation moved this from To do to Done Oct 5, 2021
@dantownsend
Copy link
Member Author

@gmos There's a new version on PyPI which supports this feature now. Hopefully it solves your issue.

This should now work:

class LoraKey(Table, tablename="copy_lora_key", db=DB):
    class_ = Varchar(null=False, length=1, db_column_name='class')

@dantownsend
Copy link
Member Author

There's also this approach for anyone coming across this in the future:

def create_table_class(

So it's:

from piccolo.table import create_table_class

LoraKey = create_table_class(
    class_kwargs={'tablename': 'copy_lora_key', 'db': DB},
    class_members={'class': Varchar(null=False, length=1)}
)

A bit harder to read, but useful in a pinch.

@gmos
Copy link
Contributor

gmos commented Oct 5, 2021

Just installed the new version. Works perfectly. Thnx.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
Development

Successfully merging a pull request may close this issue.

2 participants