Skip to content
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

Prefer [] over [""] for blank values that are split #839

Merged
merged 4 commits into from
Aug 2, 2023

Conversation

orangewolf
Copy link
Member

No description provided.

@orangewolf orangewolf added minor-ver for release notes bug-fix labels Jul 20, 2023
@bkiahstroud
Copy link
Contributor

irb(main):002:0> [].blank?
=> true
irb(main):003:0> [""].blank?
=> false

This ^ is the only potential issue with this change that I can think of off the top of my head; if a project is doing presence checks on "empty" values and that logic depends on the original behavior.

@jeremyf
Copy link
Contributor

jeremyf commented Aug 2, 2023

This may offer a partial solution to:

jeremyf added a commit that referenced this pull request Aug 2, 2023
Prior to this commit, when exporting a FileSet and GenericWork we'd see
a "creator_1" and "creator" column.  The "creator" column might look as
follows: `["Sandra Samvera"]`.  Which meant that creator was not an
`ActiveTriples::Relation` (based on the prior logic).  Yet the "creator"
field was stored as multi-value.  Perhaps having been previously coerced
into an Array.

With this commit, we're favoring the Bulkrax parser field mapping
`"join"` configuration over whether or not the object is an
=ActiveTriples::Relation=.  That is to say, if you told us to join the
field, we're going to do that regardless of the data we have.

Likewise, if the field's value is not an enumerable, we're not going to
introduce an ordinal suffix (e.g. "creator_1" when we have a scalar
creator).

In other words don't do the join logic if we don't have an "array" or we
weren't told to join arrays.

Perhaps we could interrogate the model to ask if it's single value or
not?  But this reduces the implementation knowledge of the properties by
looking at a more primitive level (is the data multi-valued or not).

Related to:

- scientist-softserv/palni-palci#624
- #839
jeremyf added a commit that referenced this pull request Aug 2, 2023
Prior to this commit, when exporting a FileSet and GenericWork we'd see
a "creator_1" and "creator" column.  The "creator" column might look as
follows: `["Sandra Samvera"]`.  Which meant that creator was not an
`ActiveTriples::Relation` (based on the prior logic).  Yet the "creator"
field was stored as multi-value.  Perhaps having been previously coerced
into an Array.

With this commit, we're favoring the Bulkrax parser field mapping
`"join"` configuration over whether or not the object is an
=ActiveTriples::Relation=.  That is to say, if you told us to join the
field, we're going to do that regardless of the data we have.

Likewise, if the field's value is not an enumerable, we're not going to
introduce an ordinal suffix (e.g. "creator_1" when we have a scalar
creator).

In other words don't do the join logic if we don't have an "array" or we
weren't told to join arrays.

Perhaps we could interrogate the model to ask if it's single value or
not?  But this reduces the implementation knowledge of the properties by
looking at a more primitive level (is the data multi-valued or not).

Related to:

- scientist-softserv/palni-palci#624
- #839
@jeremyf jeremyf merged commit f2c2652 into main Aug 2, 2023
6 checks passed
@jeremyf jeremyf deleted the no_blank_strings_on_split branch August 2, 2023 19:16
jeremyf added a commit that referenced this pull request Aug 2, 2023
Prior to this commit, when exporting a FileSet and GenericWork we'd see
a "creator_1" and "creator" column.  The "creator" column might look as
follows: `["Sandra Samvera"]`.  Which meant that creator was not an
`ActiveTriples::Relation` (based on the prior logic).  Yet the "creator"
field was stored as multi-value.  Perhaps having been previously coerced
into an Array.

With this commit, we're favoring the Bulkrax parser field mapping
`"join"` configuration over whether or not the object is an
=ActiveTriples::Relation=.  That is to say, if you told us to join the
field, we're going to do that regardless of the data we have.

Likewise, if the field's value is not an enumerable, we're not going to
introduce an ordinal suffix (e.g. "creator_1" when we have a scalar
creator).

In other words don't do the join logic if we don't have an "array" or we
weren't told to join arrays.

Perhaps we could interrogate the model to ask if it's single value or
not?  But this reduces the implementation knowledge of the properties by
looking at a more primitive level (is the data multi-valued or not).

Related to:

- scientist-softserv/palni-palci#624
- #839
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug-fix minor-ver for release notes
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants