-
Notifications
You must be signed in to change notification settings - Fork 51
fix publish to store placeholders of proper type #1952
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
Conversation
|
This is because publish is creating rows in the field table when there is no value defined. In the GUI, if you leave one of these blank, then there will not be a row in the field table. Publish is creating a row, and the default value in that row (the zero) displays because no value was defined in chado that could replace it. |
I wanted to test that this PR will not break an existing site.On a 4.x docker I entered a contact and array design and published those. Then I switched to this branch and added two more and again published. We look at the drupal field table and see that the records entered while on the 4.x branch have NULL while the record from this branch has the correct empty value ''. There are two contacts on the 4.x branch because the null contact was published also. The same for the arraydesign table: This next table shows that after this PR we don't add a row to the table if there is no underlying chado value. The value here was from the first array design on 4.x. On this branch a row was not inserted. And FinallyThis also fixes the bug where we have a bunch of field headers for fields that don't have a value! If published on the 4.x branchIf published on this branch |
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 I tested the organism as suggested but received unexpected behaviour 🙈
- There was no record in tripal_entity__organism_comment for Tripalus bogusii. This makes sense if by "no longer add rows when the underlying Chado record is empty" in the description you meant "doesn't add a record to the drupal table for a field that doesn't have a value in the linked chado record" but doesn't match what you said to expect in the testing instructions.
- When you go to the published page, the title replacement no longer works as expected 🙈 Specifically, the title is
Tripalus bogusii [organism_infraspecific_type] [organism_infraspecific_name]. This is likely a side effect of the fact that the tripal_entity__organism_infraspecific_name table no longer has an record for the infraspecific name whereas before it did but it was empty.
Note: Interestingly when I edit the organism and then save again without making changes, it fixes the title but does not add a record to the tripal_entity__organism_infraspecific_name or tripal_entity__organism_comment tables 🤔
Note: I did also enter an organism with a comment and can confirm that when the comment is present, the organism_comment_value column is now an empty string as expected --no null :-)
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.
Ok code review completed :-)
Also, after a cofest discussion, I confirmed that the following issues from my manual test are not caused by this PR:
- There was no record in tripal_entity__organism_comment for Tripalus bogusii.
This was just outdated testing instructions 🤪 They have been updated.
- When you go to the published page, the title replacement no longer works as expected
This is being fixed in issue #1956 and was not caused by this PR. This PR does exacerbate the issue though as now both type and name are not replaced in the title whereas before this PR it was only name.
tripal_chado/tests/src/Kernel/Services/TripalEntityLookupServiceTest.php
Show resolved
Hide resolved
|
Here is something I did not understand. For fields with unlimited cardinality, when an entity is created through the GUI, if there is no record, then the drupal field table does not have a row. That's how this PR works now. HOWEVER, if the field is cardinality 1, then the drupal field table DOES have a row! |
|
Looking up cardinality is easy, but the problem that is happening in this PR is that, in the tripal/tripal/src/Services/TripalPublish.php Lines 794 to 795 in 3ad2f09
there is nothing there for that field. In 4.x, there was a record in the $match, although it was empty except for the record_id. |
I am seeing quite a few bugs related to this in my production site 🤔 Perhaps we shouldn't do this. Rather if there is a chado record for that field then there is a record in drupal even if it is empty. |
|
I can see how this might make better sense. We would have to figure out how to handle integer fields, though, that have zero as an empty value, which caused the problem in this comment #1952 (comment) - although we could back to storing NULLs now that the formatter won't break from those. @laceysanderson did you mean your production site problems are on 4.x or testing on this branch? If we abandon this whole thing, well that's okay. |
Ah yes, I should have been more clear. I have tested this branch on a clone of my production site and I think there were still issues though at this point I'm having trouble determining which issues were on 4.x and which were still on this branch 🤪 I do not want to abandon this all together as I think many of the changes are great! I just think we should go back to always having a drupal record if there is a chado record.
Ah yes... I think we should leave a default of 0 for integer fields and create a new issue for this. I think I would be tempted to solve it with an option in the formatter for integer fields that lets you indicate if you want to hide entries with a value of 0 or not 🤔 but there may be a better option. |
|
With commit 6ade77f I have made two significant changes
I will now go back and update the testing procedure yet again as I test this ... |
|
Something to check, what about this NULL in a property field: bundle | deleted | entity_id | revision_id | langcode | delta | pub_abstract_record_id | pub_abstract_prop_id | pub_abstract_linker_id | pub_abstract_value | pub_abstract_rank | pub_abstract_type_id
--------+---------+-----------+-------------+----------+-------+------------------------+----------------------+------------------------+--------------------+-------------------+----------------------
pub | 0 | 6 | 1 | und | 0 | 1 | <NULL> | 1 | | 0 | 0
(1 row)and several others, authors, citation, doi... If you enter a pub with gui and the field is blank, no row is created in the drupal field table for these, even though cardinality is 1 😖 With commit 6ade77f I am checking for cardinality 1 fields where the main property is NULL as opposed to empty, and for these do not create a drupal field table entry. |
|
With commit b2f0fbf I have abandoned using cardinality. Now, add to drupal tables except for the case where there is a property with "revision id for an unversioned entity type is the same as the entity id" |
|
I have also fixed |
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.
✅ Code changes look good
✅ Manually tested on a clone of my production site and it works beautifully with our project-based grant, study and experiment pages. It correctly published a complex set of multiple property types, contact relationships, and dbxref associations. It did not break or interact badly with existing content either 😌
✅ Manually tested according to the instructions on a fresh Tripal docker and all looked as expected!
Thanks for all the hard work @dsenalik!!! This is ready to merge!!! 🎉
Bug Fix
Issue #1948
Closes #1956
Tripal Version: 4.x
Description
This PR updates the publish function to
no longer store NULLs in the drupal field tables
no longer add rows to the drupal field table when the field has any property where
drupal_storeis set to TRUE but there is no value for that property in Chado. This happens for linking fields or property fields.It also adds a
getDefaultValue()to the property type classes that specifies the appropriate type of value to store as a placeholder in the drupal field tables.Publish now stores these placeholder values in the field tables, which matches exactly what is stored when you enter an entity through the GUI.
Testing?
tripal_entity__organism_dbxreftripal_entity__organism_pubf.