1.0 release

[pawamoy]

Hello! Just curious: do you still consider ormar to be in a beta state? Are you planning something for a 1.0 release? If not, it's totally fine! Just wanted to know if something was planned 🙂

[collerek]

Hi (and thank you for your sponsoring, awesome! 😁 ),

Yeah, I still consider this as beta as before 1.0 I want to add composite pks (#137) - working on it as of now, but that one is complicated and takes a lot of time.

And since there might be a substantial change in the API I don't want to deceive the users.

One of the planned changes will be to rename the ForeignKey to OneToMany to also incorporate OneToOne (to be added) and ManyToOne (reverse fk). That way you can not only declare relation from whichever side you want but also from both sides at the same time -> that will help the autocompletion and typing as now reversed relations (that are registered dynamically) are not well handled (no autocompletion in IDE and revealed mypy type is Any).

I would also like to clean the code a little and enhance support for types and autocompletion even more (check what I can do about field accessors when you want to.

I'm not sure if I really like the Django style notation (it's convenient but it's a lot of typing). I know that a lot of people are familiar with the notation/API but I'm thinking about shortening the access to common Queryset methods:

I.e. Model.objects.select_related() would become i.e. Model.join() -> just a rough idea, no concrete plans and specification for a complete API set. I'm just not so fond of long chains of commands that you need to write to compose a complicated/long query. I know that there should be one way to do stuff (zen of python! :) ), but at the same time, I'm not sure if to change the API and remove the old one or keep it as it is (so you have python and django notations next to each other).

[pawamoy]

Thank you for the detailed explanation! This all sounds very promising 🙂
And with these changes in mind, I understand the state should be kept as beta.

but also from both sides at the same time

Nice, I really hate ManyToMany because it implicitly adds foreign keys to the through model (I was avoiding it as well in Django). This will make things more explicit and easier to reason about.

I'm not sure if I really like the Django style notation

You mean .filter(package__library__name__icontains="whatever")? It's indeed very convenient and allows the developer to avoid importing all the required models to build a query. But the Python style feels cleaner I think (less magic), and being able to AND or OR filters with & and | is very convenient as well. By the way I noticed a typo: Product.name='Test' should be Product.name=='Test' in the docs right 😄?

[collerek]

By the way I noticed a typo: Product.name='Test' should be Product.name=='Test' in the docs right 😄?

Can you issue a pr with the fix, that is a typo but where is it :)

Yeah, good point with avoiding the imports. Although with python style you also need only the main model (the one you query from), just instead of under separated __ you go with attributes Model.library.name.icontains (so in perfect scenario you should have autocompletion etc.). With parameters like name__name2 or strings, it's easy to make a typo that will pop out only at runtime.

Yes, the ability to declare your own foreign keys on through models is also one of the things I would like to improve. For now, you can only customize the name of those fields that are indeed auto-generated.