✨ Increase number_of_types to 8 to support longer select queries

[GiorgioPorgio]

I am trying to write a select statement that selects 5 different SQLModel children. However I get a type error as the overloads for select are limited to 4.

I am aware there is a PR that adds typing for select for arbitrary length :)
Since that one is not merged and has conflicts (I think) I thought to give you the option to stick to the original appraoch of autogenerating types in the meantime. I increased the number of types and run the script.

Feel free to close my PR if you would rather take another approach but I think it's a quick win!

Resolves92, 271

Thank you :)

[svlandeg]

Hi, thanks for your contribution!

It looks like the CI is failing, I'm not exactly sure why though. I'll put the PR in draft until the CI is green.

Then again, I think that perhaps it makes most sense to work on the PR that has the more generic fix. The conflicts usually just mean that the PR edits the same file as another PR that has already been merged into main - it's not necessarily an actual conflict or issue.

[GiorgioPorgio]

Hi @svlandeg

Thank you for getting back to me!
I'm not sure if @maxispeicher is active to resolve the conflicts and I did not have permissions to work on their branch. So I just changed this branch here to apply their changes adapted to the new filenames since they opened their PR.

So this branch should be good now. Credits to @maxispeicher ofc :)

Edit: did not change my branch name because I'd have to open a new PR I think and we'd lose the conversation context

[GiorgioPorgio]

After testing in a large project, I am not sure this approach can work. There are the automatically generated types such as

@overload
def select( # type: ignore
__ent0: _TCCA[_T0],
__ent1: _TCCA[_T1],
) -> Select[Tuple[_T0, _T1]]: ..

This overload would result in less specific typing and would break consumers relying on the less specific typing:

@overload
def select(*entities: _TCCA[_T0]) -> Select[Tuple[_T0, ...]]: # type: ignore
...

select(ClassA, ClassB) would be typed as Select[Tuple[ClassA | ClassB, ...]] instead of Select[Tuple[ClassA, ClassB]]

So I do not think this approach is viable.
I apologise for the confusion, I should have tested better :)

Unfortunately, I cannot think of a solution other than pre-generating types as we originally did.
I will close the PR so it won't get accidentally merged now it is approved.

Happy to pick this issue up in another PR if we find an agreeable way forward!

Thank you very much!

[svlandeg]

So I do not think this approach is viable.
I apologise for the confusion, I should have tested better :)

No need to apologize, definitely appreciate the time and effort you spent, even if it's not mergeable right now! 🙏

[GiorgioPorgio]

I am trying to write a select statement that selects 5 different SQLModel children. However I get a type error as the overloads for select are limited to 4.

I am aware there is a PR that adds typing for select for arbitrary length :)
Since that one is not merged and has conflicts (I think) I thought to give you the option to stick to the original appraoch of autogenerating types in the meantime. I increased the number of types and run the script.

Feel free to close my PR if you would rather take another approach but I think it's a quick win!

Resolves92, 271

Thank you :)

[svlandeg]

Hi, thanks for your contribution!

It looks like the CI is failing, I'm not exactly sure why though. I'll put the PR in draft until the CI is green.

Then again, I think that perhaps it makes most sense to work on the PR that has the more generic fix. The conflicts usually just mean that the PR edits the same file as another PR that has already been merged into main - it's not necessarily an actual conflict or issue.

[GiorgioPorgio]

Hi @svlandeg

Thank you for getting back to me!
I'm not sure if @maxispeicher is active to resolve the conflicts and I did not have permissions to work on their branch. So I just changed this branch here to apply their changes adapted to the new filenames since they opened their PR.

So this branch should be good now. Credits to @maxispeicher ofc :)

Edit: did not change my branch name because I'd have to open a new PR I think and we'd lose the conversation context

[GiorgioPorgio]

After testing in a large project, I am not sure this approach can work. There are the automatically generated types such as

@overload
def select( # type: ignore
__ent0: _TCCA[_T0],
__ent1: _TCCA[_T1],
) -> Select[Tuple[_T0, _T1]]: ..

This overload would result in less specific typing and would break consumers relying on the less specific typing:

@overload
def select(*entities: _TCCA[_T0]) -> Select[Tuple[_T0, ...]]: # type: ignore
...

select(ClassA, ClassB) would be typed as Select[Tuple[ClassA | ClassB, ...]] instead of Select[Tuple[ClassA, ClassB]]

So I do not think this approach is viable.
I apologise for the confusion, I should have tested better :)

Unfortunately, I cannot think of a solution other than pre-generating types as we originally did.
I will close the PR so it won't get accidentally merged now it is approved.

Happy to pick this issue up in another PR if we find an agreeable way forward!

Thank you very much!

[svlandeg]

So I do not think this approach is viable.
I apologise for the confusion, I should have tested better :)

No need to apologize, definitely appreciate the time and effort you spent, even if it's not mergeable right now! 🙏

[GiorgioPorgio]

I am trying to write a select statement that selects 5 different SQLModel children. However I get a type error as the overloads for select are limited to 4.

I am aware there is a PR that adds typing for select for arbitrary length :)
Since that one is not merged and has conflicts (I think) I thought to give you the option to stick to the original appraoch of autogenerating types in the meantime. I increased the number of types and run the script.

Feel free to close my PR if you would rather take another approach but I think it's a quick win!

Resolves92, 271

Thank you :)

[svlandeg]

Hi, thanks for your contribution!

It looks like the CI is failing, I'm not exactly sure why though. I'll put the PR in draft until the CI is green.

Then again, I think that perhaps it makes most sense to work on the PR that has the more generic fix. The conflicts usually just mean that the PR edits the same file as another PR that has already been merged into main - it's not necessarily an actual conflict or issue.

[GiorgioPorgio]

Hi @svlandeg

Thank you for getting back to me!
I'm not sure if @maxispeicher is active to resolve the conflicts and I did not have permissions to work on their branch. So I just changed this branch here to apply their changes adapted to the new filenames since they opened their PR.

So this branch should be good now. Credits to @maxispeicher ofc :)

Edit: did not change my branch name because I'd have to open a new PR I think and we'd lose the conversation context

[GiorgioPorgio]

After testing in a large project, I am not sure this approach can work. There are the automatically generated types such as

@overload
def select( # type: ignore
__ent0: _TCCA[_T0],
__ent1: _TCCA[_T1],
) -> Select[Tuple[_T0, _T1]]: ..

This overload would result in less specific typing and would break consumers relying on the less specific typing:

@overload
def select(*entities: _TCCA[_T0]) -> Select[Tuple[_T0, ...]]: # type: ignore
...

select(ClassA, ClassB) would be typed as Select[Tuple[ClassA | ClassB, ...]] instead of Select[Tuple[ClassA, ClassB]]

So I do not think this approach is viable.
I apologise for the confusion, I should have tested better :)

Unfortunately, I cannot think of a solution other than pre-generating types as we originally did.
I will close the PR so it won't get accidentally merged now it is approved.

Happy to pick this issue up in another PR if we find an agreeable way forward!

Thank you very much!

[svlandeg]

So I do not think this approach is viable.
I apologise for the confusion, I should have tested better :)

No need to apologize, definitely appreciate the time and effort you spent, even if it's not mergeable right now! 🙏

[GiorgioPorgio]

I am trying to write a select statement that selects 5 different SQLModel children. However I get a type error as the overloads for select are limited to 4.

I am aware there is a PR that adds typing for select for arbitrary length :)
Since that one is not merged and has conflicts (I think) I thought to give you the option to stick to the original appraoch of autogenerating types in the meantime. I increased the number of types and run the script.

Feel free to close my PR if you would rather take another approach but I think it's a quick win!

Resolves92, 271

Thank you :)

[svlandeg]

Hi, thanks for your contribution!

It looks like the CI is failing, I'm not exactly sure why though. I'll put the PR in draft until the CI is green.

Then again, I think that perhaps it makes most sense to work on the PR that has the more generic fix. The conflicts usually just mean that the PR edits the same file as another PR that has already been merged into main - it's not necessarily an actual conflict or issue.

[GiorgioPorgio]

Hi @svlandeg

Thank you for getting back to me!
I'm not sure if @maxispeicher is active to resolve the conflicts and I did not have permissions to work on their branch. So I just changed this branch here to apply their changes adapted to the new filenames since they opened their PR.

So this branch should be good now. Credits to @maxispeicher ofc :)

Edit: did not change my branch name because I'd have to open a new PR I think and we'd lose the conversation context

[GiorgioPorgio]

After testing in a large project, I am not sure this approach can work. There are the automatically generated types such as

@overload
def select( # type: ignore
__ent0: _TCCA[_T0],
__ent1: _TCCA[_T1],
) -> Select[Tuple[_T0, _T1]]: ..

This overload would result in less specific typing and would break consumers relying on the less specific typing:

@overload
def select(*entities: _TCCA[_T0]) -> Select[Tuple[_T0, ...]]: # type: ignore
...

select(ClassA, ClassB) would be typed as Select[Tuple[ClassA | ClassB, ...]] instead of Select[Tuple[ClassA, ClassB]]

So I do not think this approach is viable.
I apologise for the confusion, I should have tested better :)

Unfortunately, I cannot think of a solution other than pre-generating types as we originally did.
I will close the PR so it won't get accidentally merged now it is approved.

Happy to pick this issue up in another PR if we find an agreeable way forward!

Thank you very much!

[svlandeg]

So I do not think this approach is viable.
I apologise for the confusion, I should have tested better :)

No need to apologize, definitely appreciate the time and effort you spent, even if it's not mergeable right now! 🙏

[GiorgioPorgio]

I am trying to write a select statement that selects 5 different SQLModel children. However I get a type error as the overloads for select are limited to 4.

I am aware there is a PR that adds typing for select for arbitrary length :)
Since that one is not merged and has conflicts (I think) I thought to give you the option to stick to the original appraoch of autogenerating types in the meantime. I increased the number of types and run the script.

Feel free to close my PR if you would rather take another approach but I think it's a quick win!

Resolves92, 271

Thank you :)

[svlandeg]

Hi, thanks for your contribution!

It looks like the CI is failing, I'm not exactly sure why though. I'll put the PR in draft until the CI is green.

Then again, I think that perhaps it makes most sense to work on the PR that has the more generic fix. The conflicts usually just mean that the PR edits the same file as another PR that has already been merged into main - it's not necessarily an actual conflict or issue.

[GiorgioPorgio]

Hi @svlandeg

Thank you for getting back to me!
I'm not sure if @maxispeicher is active to resolve the conflicts and I did not have permissions to work on their branch. So I just changed this branch here to apply their changes adapted to the new filenames since they opened their PR.

So this branch should be good now. Credits to @maxispeicher ofc :)

Edit: did not change my branch name because I'd have to open a new PR I think and we'd lose the conversation context

[GiorgioPorgio]

After testing in a large project, I am not sure this approach can work. There are the automatically generated types such as

@overload
def select( # type: ignore
__ent0: _TCCA[_T0],
__ent1: _TCCA[_T1],
) -> Select[Tuple[_T0, _T1]]: ..

This overload would result in less specific typing and would break consumers relying on the less specific typing:

@overload
def select(*entities: _TCCA[_T0]) -> Select[Tuple[_T0, ...]]: # type: ignore
...

select(ClassA, ClassB) would be typed as Select[Tuple[ClassA | ClassB, ...]] instead of Select[Tuple[ClassA, ClassB]]

So I do not think this approach is viable.
I apologise for the confusion, I should have tested better :)

Unfortunately, I cannot think of a solution other than pre-generating types as we originally did.
I will close the PR so it won't get accidentally merged now it is approved.

Happy to pick this issue up in another PR if we find an agreeable way forward!

Thank you very much!

[svlandeg]

So I do not think this approach is viable.
I apologise for the confusion, I should have tested better :)

No need to apologize, definitely appreciate the time and effort you spent, even if it's not mergeable right now! 🙏

[GiorgioPorgio]

I am trying to write a select statement that selects 5 different SQLModel children. However I get a type error as the overloads for select are limited to 4.

I am aware there is a PR that adds typing for select for arbitrary length :)
Since that one is not merged and has conflicts (I think) I thought to give you the option to stick to the original appraoch of autogenerating types in the meantime. I increased the number of types and run the script.

Feel free to close my PR if you would rather take another approach but I think it's a quick win!

Resolves92, 271

Thank you :)

[svlandeg]

Hi, thanks for your contribution!

It looks like the CI is failing, I'm not exactly sure why though. I'll put the PR in draft until the CI is green.

Then again, I think that perhaps it makes most sense to work on the PR that has the more generic fix. The conflicts usually just mean that the PR edits the same file as another PR that has already been merged into main - it's not necessarily an actual conflict or issue.

[GiorgioPorgio]

Hi @svlandeg

Thank you for getting back to me!
I'm not sure if @maxispeicher is active to resolve the conflicts and I did not have permissions to work on their branch. So I just changed this branch here to apply their changes adapted to the new filenames since they opened their PR.

So this branch should be good now. Credits to @maxispeicher ofc :)

Edit: did not change my branch name because I'd have to open a new PR I think and we'd lose the conversation context

[GiorgioPorgio]

After testing in a large project, I am not sure this approach can work. There are the automatically generated types such as

@overload
def select( # type: ignore
__ent0: _TCCA[_T0],
__ent1: _TCCA[_T1],
) -> Select[Tuple[_T0, _T1]]: ..

This overload would result in less specific typing and would break consumers relying on the less specific typing:

@overload
def select(*entities: _TCCA[_T0]) -> Select[Tuple[_T0, ...]]: # type: ignore
...

select(ClassA, ClassB) would be typed as Select[Tuple[ClassA | ClassB, ...]] instead of Select[Tuple[ClassA, ClassB]]

So I do not think this approach is viable.
I apologise for the confusion, I should have tested better :)

Unfortunately, I cannot think of a solution other than pre-generating types as we originally did.
I will close the PR so it won't get accidentally merged now it is approved.

Happy to pick this issue up in another PR if we find an agreeable way forward!

Thank you very much!

[svlandeg]

So I do not think this approach is viable.
I apologise for the confusion, I should have tested better :)

No need to apologize, definitely appreciate the time and effort you spent, even if it's not mergeable right now! 🙏

[GiorgioPorgio]

I am trying to write a select statement that selects 5 different SQLModel children. However I get a type error as the overloads for select are limited to 4.

I am aware there is a PR that adds typing for select for arbitrary length :)
Since that one is not merged and has conflicts (I think) I thought to give you the option to stick to the original appraoch of autogenerating types in the meantime. I increased the number of types and run the script.

Feel free to close my PR if you would rather take another approach but I think it's a quick win!

Resolves92, 271

Thank you :)

[svlandeg]

Hi, thanks for your contribution!

It looks like the CI is failing, I'm not exactly sure why though. I'll put the PR in draft until the CI is green.

Then again, I think that perhaps it makes most sense to work on the PR that has the more generic fix. The conflicts usually just mean that the PR edits the same file as another PR that has already been merged into main - it's not necessarily an actual conflict or issue.

[GiorgioPorgio]

Hi @svlandeg

Thank you for getting back to me!
I'm not sure if @maxispeicher is active to resolve the conflicts and I did not have permissions to work on their branch. So I just changed this branch here to apply their changes adapted to the new filenames since they opened their PR.

So this branch should be good now. Credits to @maxispeicher ofc :)

Edit: did not change my branch name because I'd have to open a new PR I think and we'd lose the conversation context

[GiorgioPorgio]

After testing in a large project, I am not sure this approach can work. There are the automatically generated types such as

@overload
def select( # type: ignore
__ent0: _TCCA[_T0],
__ent1: _TCCA[_T1],
) -> Select[Tuple[_T0, _T1]]: ..

This overload would result in less specific typing and would break consumers relying on the less specific typing:

@overload
def select(*entities: _TCCA[_T0]) -> Select[Tuple[_T0, ...]]: # type: ignore
...

select(ClassA, ClassB) would be typed as Select[Tuple[ClassA | ClassB, ...]] instead of Select[Tuple[ClassA, ClassB]]

So I do not think this approach is viable.
I apologise for the confusion, I should have tested better :)

Unfortunately, I cannot think of a solution other than pre-generating types as we originally did.
I will close the PR so it won't get accidentally merged now it is approved.

Happy to pick this issue up in another PR if we find an agreeable way forward!

Thank you very much!

[svlandeg]

So I do not think this approach is viable.
I apologise for the confusion, I should have tested better :)

No need to apologize, definitely appreciate the time and effort you spent, even if it's not mergeable right now! 🙏

[GiorgioPorgio]

I am trying to write a select statement that selects 5 different SQLModel children. However I get a type error as the overloads for select are limited to 4.

I am aware there is a PR that adds typing for select for arbitrary length :)
Since that one is not merged and has conflicts (I think) I thought to give you the option to stick to the original appraoch of autogenerating types in the meantime. I increased the number of types and run the script.

Feel free to close my PR if you would rather take another approach but I think it's a quick win!

Resolves92, 271

Thank you :)

[svlandeg]

Hi, thanks for your contribution!

It looks like the CI is failing, I'm not exactly sure why though. I'll put the PR in draft until the CI is green.

Then again, I think that perhaps it makes most sense to work on the PR that has the more generic fix. The conflicts usually just mean that the PR edits the same file as another PR that has already been merged into main - it's not necessarily an actual conflict or issue.

[GiorgioPorgio]

Hi @svlandeg

Thank you for getting back to me!
I'm not sure if @maxispeicher is active to resolve the conflicts and I did not have permissions to work on their branch. So I just changed this branch here to apply their changes adapted to the new filenames since they opened their PR.

So this branch should be good now. Credits to @maxispeicher ofc :)

Edit: did not change my branch name because I'd have to open a new PR I think and we'd lose the conversation context

[GiorgioPorgio]

After testing in a large project, I am not sure this approach can work. There are the automatically generated types such as

@overload
def select( # type: ignore
__ent0: _TCCA[_T0],
__ent1: _TCCA[_T1],
) -> Select[Tuple[_T0, _T1]]: ..

This overload would result in less specific typing and would break consumers relying on the less specific typing:

@overload
def select(*entities: _TCCA[_T0]) -> Select[Tuple[_T0, ...]]: # type: ignore
...

select(ClassA, ClassB) would be typed as Select[Tuple[ClassA | ClassB, ...]] instead of Select[Tuple[ClassA, ClassB]]

So I do not think this approach is viable.
I apologise for the confusion, I should have tested better :)

Unfortunately, I cannot think of a solution other than pre-generating types as we originally did.
I will close the PR so it won't get accidentally merged now it is approved.

Happy to pick this issue up in another PR if we find an agreeable way forward!

Thank you very much!

[svlandeg]

So I do not think this approach is viable.
I apologise for the confusion, I should have tested better :)

No need to apologize, definitely appreciate the time and effort you spent, even if it's not mergeable right now! 🙏