This repository has been archived by the owner on Jul 19, 2021. It is now read-only.
Task rails generate binda:setup is broken (undefined method `choices') #228
Labels
Comments
|
The issue is related to the new ActiveJob feature. This feature runs at every It'd be great if it was possible to add a callback to this ActiveJob and pass it as a parameter. The problem is that I don't think it can be done via the Refer to this piece of code. |
|
@Marchino is |
|
@thauma9 After digging more on the subject I have come to the conclusion that there is no way to know what's the state of the cue when you are using the default cue adapter ( I can see two possible solutions:
@Marchino, any suggestion? |
|
Hello,
sorry for the delay, I have been pretty busy at work.
I read through the issue and I hope I’m understanding this correctly.
I think what happens is that since the code doesn’t wait for the component
updatets, it tries to do something to a field that hasn’t been created yet.
One easy way to fix this problem mightbe to force
config.active_job.queue_adapter to :inline inside the generator and put it
back to :async when the task has been completed.
This way, during the setup, Binda would behave as if there was no queue.
Another thing we could do, to answer Alessandro’s concerns about data
integrity, is wrap the asynchronous jobs code inside a database transaction
so that nothing gets committed to the database if something prevents the
job to finish.
Let me know if this sounds good or not.
Thank you
…--
Marco Crepaldi
On 24 maggio 2019 a 13:44:14, Alessandro ([email protected]) scritto:
@thauma9 <https://github.com/thauma9> After digging more on the subject I
have come to the conclusion that there is no way to know what's the state
of the cue when you are using the default cue adapter (:inline). Therefore
you cannot know if your component has been updated unless you are polling a
function that checks it.
I can see two possible solutions:
1. We move the optimisation to a plugin where you are asked to use a
backend (Rescue, Sidekiq, or similar), this way you don't have to put
Sidekiq as a dependency, but if you like you can add that plugin.
2. We make the component aware that is going to be updated adding a
state updating which is stored in the database.
@Marchino <https://github.com/Marchino>, any suggestion?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#228?email_source=notifications&email_token=AAAENVBCY5DPSGPSQL4ITDLPW7II5A5CNFSM4HNKQZAKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODWFBKYY#issuecomment-495588707>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAAENVFPOJ4K3S4VRIVLTP3PW7II5ANCNFSM4HNKQZAA>
.
|
I'm currently not setting any My guess is that the application doesn't wait for the job to finish even though is Can you confirm you can reproduce the same issue? |
|
I think the default adapter is async or something like that. I am sure I
had to force it to inline for tests because I needed results before making
assertions.
Il giorno ven 24 mag 2019 alle 19:31 Alessandro <[email protected]>
ha scritto:
One easy way to fix this problem might be to force
config.active_job.queue_adapter to :inline
I'm currently not setting any queue_adapter which means I'm using :inline(Rails
default adapter), but it throws an error.
My guess is that the application doesn't wait for the job to finish even
though is :inline.
Can you confirm you can reproduce the same issue?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#228?email_source=notifications&email_token=AAAENVHPSEZC6MJIRX5AW3LPXAQ67A5CNFSM4HNKQZAKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODWGB44A#issuecomment-495722096>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAAENVGV42GQYA3XKZLOE63PXAQ67ANCNFSM4HNKQZAA>
.
--
Marco
http://about.me/marcocrepaldi
|
|
This is good to know. No matter what’s the default it’d be a good idea to set :inline explicitly. My concern is that you don’t want to change Rails default behaviour, it should rather be the developer decision to change adapter.
So I wouldn’t change it automatically when installing Binda. At the same time I’d like everyone to be able to use the software without having to manually complete the installation.
My current idea is to move the active job and make it optional.
A B
Il giorno 24 mag 2019, alle ore 19:35, Marco Crepaldi <[email protected]> ha scritto:
… I think the default adapter is async or something like that. I am sure I
had to force it to inline for tests because I needed results before making
assertions.
Il giorno ven 24 mag 2019 alle 19:31 Alessandro ***@***.***>
ha scritto:
> One easy way to fix this problem might be to force
> config.active_job.queue_adapter to :inline
> I'm currently not setting any queue_adapter which means I'm using :inline(Rails
> default adapter), but it throws an error.
>
> My guess is that the application doesn't wait for the job to finish even
> though is :inline.
>
> Can you confirm you can reproduce the same issue?
>
> —
> You are receiving this because you were mentioned.
>
>
> Reply to this email directly, view it on GitHub
> <#228?email_source=notifications&email_token=AAAENVHPSEZC6MJIRX5AW3LPXAQ67A5CNFSM4HNKQZAKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODWGB44A#issuecomment-495722096>,
> or mute the thread
> <https://github.com/notifications/unsubscribe-auth/AAAENVGV42GQYA3XKZLOE63PXAQ67ANCNFSM4HNKQZAA>
> .
>
--
Marco
http://about.me/marcocrepaldi
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.
|
|
I don’t want to change anything actually.
I just think that we could set the inline behavior just for the setup
process since that is a linear and synchronous task.
The application behaviour can stay asynchronous because all we care is that
responses are fast.
To avoid data inconsistencies we just need to wrap the async code in a
database transaction so that data get committed to the database only when
everything is completed.
I hope this makes more sense.
|
|
Very good, I trust you. Maybe I’m not understanding what you mean by database transaction.
I’d love to try implementing a solution.
A B
Il giorno 24 mag 2019, alle ore 20:50, Marco Crepaldi <[email protected]> ha scritto:
… I don’t want to change anything actually.
I just think that we could set the inline behavior just for the setup
process since that is a linear and synchronous task.
The application behaviour can stay asynchronous because all we care is that
responses are fast.
To avoid data inconsistencies we just need to wrap the async code in a
database transaction so that data get committed to the database only when
everything is completed.
I hope this makes more sense.
Il giorno ven 24 mag 2019 alle 20:18 Alessandro ***@***.***>
ha scritto:
> This is good to know. No matter what’s the default it’d be a good idea to
> set :inline explicitly. My concern is that you don’t want to change Rails
> default behaviour, it should rather be the developer decision to change
> adapter.
>
> So I wouldn’t change it automatically when installing Binda. At the same
> time I’d like everyone to be able to use the software without having to
> manually complete the installation.
>
> My current idea is to move the active job and make it optional.
>
> A B
>
> Il giorno 24 mag 2019, alle ore 19:35, Marco Crepaldi <
> ***@***.***> ha scritto:
>
> > I think the default adapter is async or something like that. I am sure I
> > had to force it to inline for tests because I needed results before
> making
> > assertions.
> >
> > Il giorno ven 24 mag 2019 alle 19:31 Alessandro <
> ***@***.***>
> > ha scritto:
> >
> > > One easy way to fix this problem might be to force
> > > config.active_job.queue_adapter to :inline
> > > I'm currently not setting any queue_adapter which means I'm using
> :inline(Rails
> > > default adapter), but it throws an error.
> > >
> > > My guess is that the application doesn't wait for the job to finish
> even
> > > though is :inline.
> > >
> > > Can you confirm you can reproduce the same issue?
> > >
> > > —
> > > You are receiving this because you were mentioned.
> > >
> > >
> > > Reply to this email directly, view it on GitHub
> > > <
> #228?email_source=notifications&email_token=AAAENVHPSEZC6MJIRX5AW3LPXAQ67A5CNFSM4HNKQZAKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODWGB44A#issuecomment-495722096
> >,
> > > or mute the thread
> > > <
> https://github.com/notifications/unsubscribe-auth/AAAENVGV42GQYA3XKZLOE63PXAQ67ANCNFSM4HNKQZAA
> >
> > > .
> > >
> > --
> > Marco
> >
> > http://about.me/marcocrepaldi
> > —
> > You are receiving this because you authored the thread.
> > Reply to this email directly, view it on GitHub, or mute the thread.
>
> —
> You are receiving this because you were mentioned.
>
>
> Reply to this email directly, view it on GitHub
> <#228?email_source=notifications&email_token=AAAENVA5W5OKCJDNM7RL4YTPXAWQPA5CNFSM4HNKQZAKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODWGGM7I#issuecomment-495740541>,
> or mute the thread
> <https://github.com/notifications/unsubscribe-auth/AAAENVDTRAOQJOY3S3SSRITPXAWQPANCNFSM4HNKQZAA>
> .
>
--
Marco
http://about.me/marcocrepaldi
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.
|
|
A database transaction is a construct that basically tells the database to
actually write data only if a series of operations completes without
errors.
In our context this means that field setting get committed to the database
only if every component is processed.
ActiveRecord lets you do something like this:
ActiveRecord::Transaction do
# a series of operations
end
Try to run rails console —sandbox, it does just that, every operation is
rolled back ad soon as you close the console.
Let me know if you need any help!
|
|
This is interesting. Always astonished to find how much I can still learn from you! 😛 I'll give it a try. |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Issue
It's not possibile to complete setup.
Expected behavior
Should complete the setup as usual.
How to reproduce the issue
rails db:drop && rails db:createrails generate binda:installReturns this error:
System configuration
Binda version: 0.1.11
Rails version: 5.2
The text was updated successfully, but these errors were encountered: