Feature discussion

[david-alm]

Hello 👋

I wanted to start off discussing a few features that I would love to see in piccolo and see whether they were valuable to the rest of the community.

Here's my preliminary list:

• Storing bytes and other BLOBS
• Compound uniqueness constraints
• Multicolumn indices

Feel free to add more!

[dantownsend]

Hi David. I just checked, and the database adapter supports bytes, so adding it shouldn't be too hard.

What use cases do you envisage for a binary column type?

Compound uniqueness constraints shouldn't be too bad. There are a few APIs I can imagine:

# option 1
class MyTable(Table, constraints=[Unique('name', 'address')]):
    name = Varchar()
    address = Text()

# option 2
class MyTable(Table):
    name = Varchar(unique_with=['address'])
    address = Text()

# option 3
class MyTable(Table):
    name = Varchar()
    address = Text()

MyTable.constraints.append(Unique(MyTable.name, MyTable.address))

Can you think of any others? My preference is to use direct references to column instances, rather than strings where possible (i.e. MyTable.name vs 'name'), but it's not essential.

I think multicolumn indexes would follow a similar design pattern.

There's a list of other features in the roadmap. I don't think an ORM is ever really finished - there's always more stuff to add, especially with Postgres! I just need to prioritise what's most important.

I'm interested to hear your thoughts.

[david-alm]

Hey Dan,

bytes could provide a cleaner interface to storing bytearrays without the space overhead of serialization. In my case, I'm looking to store the results of cryptographic operations. Though it seems that performance is better when serializing and using string fields.

As for the API design w.r.t. compound uniqueness constraints, I would also prefer references to column instances rather than strings.
Option 3 might be the cleanest syntax, though I'd prefer they were defined in the class rather than injected after initialization.

Since compound uniqueness constraints are just indices under-the-hood, I thought perhaps it made sense to kill two birds with one stone and just model these as indices with optional uniqueness constraints.
What do you think of the following?

class MyTable(Table):
    name = Varchar()
    address = Text()

    @unique
    @index
    def my_custom_index(cls):
         return Index(cls.name, cls.address)

    @index
    def some_other_index(cls):
         return Index(cls.name)

Likewise interested to hear your thoughts.

[dantownsend]

Yeah, I agree that declaring the indexes within the body of the class is cleaner - I like your solution.

I started playing around with a Bytea column. Here's the pull request for it. Is this what you imagined?

[david-alm]

That's looking really good. Thanks a ton.