-
Notifications
You must be signed in to change notification settings - Fork 390
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
feat: add v1 enpoint to set Response
status
#2756
Changes from 4 commits
f5c433c
18951a8
d56b875
a9bb122
2977dca
6ba0060
2366e83
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -18,12 +18,15 @@ | |
|
||
from pydantic import BaseModel | ||
|
||
from argilla.server.models import ResponseStatus | ||
|
||
|
||
class Response(BaseModel): | ||
id: UUID | ||
values: Dict[str, Any] | ||
record_id: UUID | ||
user_id: UUID | ||
status: ResponseStatus | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. In There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Oh, I didn't realize there was this I think it makes sense to have a
|
||
inserted_at: datetime | ||
updated_at: datetime | ||
|
||
|
@@ -33,3 +36,7 @@ class Config: | |
|
||
class ResponseUpdate(BaseModel): | ||
values: Dict[str, Any] | ||
|
||
|
||
class ResponseStatusUpdate(BaseModel): | ||
status: ResponseStatus |
gabrielmbmb marked this conversation as resolved.
Show resolved
Hide resolved
|
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.
Can you explain your rationale for modifying this database migration instead of opting to create a new one?
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.
So in the current latest version
1.6.0
, only three tables have been created and managed by alembicworkspaces
,users
, andworkspaces_users
.In the branch
feat/2615-instructions-task
, migrations files have been created for some other tables. I've opted to modify the migration file instead of generating a new one because I've assumed that as these changes have not been used yet in any production environment, it is better to modify the migration file directly to add this new column, instead of creating a new migration file for just adding one column. One more file, but a little bit more noise.Of course, if the migrations files in
feat/2615-instruction-task
were already applied in any production DB, then the logical thing to do would have been to generate a new migration script to add this new column, so alembic would have detected that there is a revision that has not been applied and that it needs to apply to the DB.Having that said, for me it was not super clear how are you planning to handle the migrations with
alembic
. Maybe it's a good idea to have one single alembic revision/script to update the DB per the released version of the package.Also, I've realized that
alembic revision --autogenerate
command cannot be used to generate migrations automatically becauseargilla/src/argilla/server/alembic/env.py
Line 37 in 5e3ecd7
target_metadata
has not been set toargilla/src/argilla/server/database.py
Line 51 in 5e3ecd7
Base.metadata
.Another doubt that I have, is that I've seen that the attributes
nullable
,index
, etc are being set in the migrations files, but not in themapped_column
function ofsqlalchemy
.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.
In your opinion, what are the benefits of utilizing automatic migrations?
In the same vein as the previous question, what are your views on the advantages of including these attributes in models?
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 that I can answer both questions at the same time 😁
So if we include these attributes in the models, then
alembic
will be available to automatically pick up them and it will generate a statement in the migration script with all the columns constraints, index, etc.I think that it's really beneficial to use
alembic
automatic migrations, becausealembic
is able to automatically detect the updates you have done in your model class, or in other words, it is able to generate adiff
between the schema generated with all the previous revisions and the one you're about to generate, and it will only create statements for the things that need to be updated.So in my opinion, it is better to let
alembic
generate the migration file automatically with theSQLAlchemy
model metadata than to let a human generate it manually and increase the chances of forgetting to include something in the migration script.