-
Notifications
You must be signed in to change notification settings - Fork 5
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
Can't create registers... _packed_id has a not null constraint. #5
Comments
Or rather registers#create. |
Hi Jamie - Thanks for the message, and sorry for the delay as I was away for the However at first glance your read of the situation sounds correct. The C On Friday, 31 October 2014, Jamie Folsom [email protected] wrote:
|
Hi @christopheryork, No worries. I solved this for now in CFRP by modifying the register model to explicitly set the next_val for the _packed_id before_create. Have a look at my branch in that repo. I am guessing you have ideas for a better solution though. Seems that should not be a concern for the implementing application. Thanks! Jamie |
Hi @jamiefolsom, Absolutely, this should not be a concern for the implementing application. I've confirmed that repertoire-faceting sets the default value correctly, For the moment, your work around is good. Once I have a solution I'll patch On Tue, Nov 4, 2014 at 2:31 PM, Jamie Folsom [email protected]
|
Hi @christopheryork -- Sounds great. Thanks! |
Bump -- just ran into this on the plays model too. Let's discuss when you have a moment. Thanks! |
Hi @christopheryork!
I am running into an issue in register#new; since _packed_id has been created (by repertoire-faceting I think), and includes a not null constraint, I can't create new registers since the model is unaware of that attribute, and doesn't know how to set a value on it that is appropriately "packed".
I could add a migration to alter the column to allow null values, I could add the attribute to attr_accessible on the model, and explicitly set a value on the object at create time, but as I recall this column is managed by repertoire-faceting.
Thoughts on the best way to manage this?
Thanks!
Jamie
The text was updated successfully, but these errors were encountered: