Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Apr 18 20:45
    mjy labeled #2186
  • Apr 18 20:45
    mjy assigned #2186
  • Apr 18 20:45
    mjy opened #2186
  • Apr 18 20:39
    mjy closed #1540
  • Apr 18 20:39
    mjy commented #1540
  • Apr 18 17:00
    mjy commented #2175
  • Apr 18 16:58

    mjy on development

    xspecify namespace test and not… (compare)

  • Apr 18 16:54

    mjy on development

    Add index to identifiers#cached (compare)

  • Apr 18 16:30
    mjy closed #2163
  • Apr 18 16:30

    mjy on development

    Fix #2163 (compare)

  • Apr 18 15:44
    mjy assigned #2163
  • Apr 18 15:43
    mjy closed #2172
  • Apr 18 15:43

    mjy on development

    Fix #2172 (compare)

  • Apr 16 21:24

    jlpereira on 1934_new_extract

    Added identifiers actions (compare)

  • Apr 16 19:22

    jlpereira on 1934_new_extract

    Fix custom attributes (compare)

  • Apr 16 19:08
    codecov-commenter commented #1981
  • Apr 16 19:08
    mjy synchronize #1981
  • Apr 16 16:17
    jlpereira synchronize #1981
  • Apr 16 16:17

    jlpereira on soft_validation_fixes

    Tweak (compare)

  • Apr 16 16:16
    jlpereira synchronize #1981
Hernán Lucas Pereira
@LocoDelAssembly
sorry..,
What is the correct procedure to make pairing_is_allowed to work for all subclasses when doing origin relationships?
Matt
@mjy
See concerns/shared/origin_relationship.rb
!! You must redundantly provide STI subclasses and parent classes if you want to allow both.  Providing
   a superclass does *not* provide the subclasses.
I fought that for a while and decided to go explicit, and by subclass. Since there are limited possibilities so far it wasn't too bad. Are you hitting issues in Datasets?
Hernán Lucas Pereira
@LocoDelAssembly
Yes, it is now crashing, so was trying to add is_origin_for/originates_from on both ends (originally only is_origin_for Person.to_s at ImportDataset).
Matt
@mjy
do you also have the inverse in both?
is_origin_for
originates_from
you likley need
Person::Vetted?
and Person::Unvetted?
Hernán Lucas Pereira
@LocoDelAssembly
Yes, that is the problem now and added originates_from ImportDataset.to_s at Person::Unvetted
Matt
@mjy
(good idea with ImportDataset.to_s approach btw
We should update everything to be that way...
)
Hernán Lucas Pereira
@LocoDelAssembly
Guess I'll have to list all descendants? Would also require adding is_origin_for to all subclasses of ImportDataset?
Matt
@mjy
I believe so, yes.
How many subclasses do you have?
Hernán Lucas Pereira
@LocoDelAssembly
["ImportDataset::DarwinCore", "ImportDataset::DarwinCore::Occurrences", "ImportDataset::DarwinCore::Checklist", "ImportDataset::DarwinCore::Unknown"] (In reality only the ones in the middle would be associated with people)
Matt
@mjy
OK. Not too bad so far.
I think in this case it's good we have explict
To further define people can only come from some of those
and not all
Hernán Lucas Pereira
@LocoDelAssembly
Should I set is_origin_for for Person::Vetted? (I create always unvetted, but eventually them transition to vetted automatically, even when importing more rows without the user doing anything)
Matt
@mjy
No, don't.
The actuall class stored in the DB is the base class.
It's just a validation step on create IIRC
I.e. add it only if we make it possible in a UI.
Hernán Lucas Pereira
@LocoDelAssembly
 OriginRelationship.group(:old_object_type,:new_object_type).count
   (0.4ms)  SELECT COUNT(*) AS count_all, "origin_relationships"."old_object_type" AS origin_relationships_old_object_type, "origin_relationships"."new_object_type" AS origin_relationships_new_object_type FROM "origin_relationships" GROUP BY "origin_relationships"."old_object_type", "origin_relationships"."new_object_type"
 => {["ImportDataset", "Person"]=>399}
Alright, so Unvetted it is. Thanks @mjy
Hernán Lucas Pereira
@LocoDelAssembly
  originates_from(*
    [
      ImportDataset::DarwinCore::Checklist,
      ImportDataset::DarwinCore::Occurrences
    ].map(&:to_s)
  )
But perhaps I just change originates_from/is_origin_for method in development branch to call to_s on all elements, right? (Which should be fully compatible with existing code). Any downside?
Matt
@mjy
It does make a requirement that the model is loaded already.
So maybe we shouldn't.
Plus side- model must exist.
Downside- creates load constraints.
Matt
@mjy
@LocoDelAssembly @jlpereira do we need to update https://github.com/SpeciesFileGroup/install_taxonworks/blob/master/development/native/macos.md to reference mime-magic updates?
Hernán Lucas Pereira
@LocoDelAssembly
Guess will have to be, because migrating to ActiveStorage causes those untrackable problems of "has_one_attached method unknown" when it shouldn't at all...
BTW, is Xcode actually required? It is a VERY heavy download even after installing it I noticed that brew downloaded it again anyway (although command line tools only)
José Luis Pereira
@jlpereira
what you mean about the mime-magic?
Matt
@mjy
brew install shared-mime-info
José Luis Pereira
@jlpereira
I didnt have to do anything different to get it work
Matt
@mjy
@LocoDelAssembly I didn't know brew loaded xcode. If it does then we don't need it again, though I can't imagine a dev env without it to start.
Hernán Lucas Pereira
@LocoDelAssembly
Try bundle update && git checkout Gemfile.lock
Matt
@mjy
@jrflood that ^
Ah, but bundle update fails for him.
I don' thtink that will work.
Hernán Lucas Pereira
@LocoDelAssembly

Try bundle update && git checkout Gemfile.lock

If it fails then you need really need to install shared-mime-info otherwise will work and Gemfile.lock will be restored so updates are not pushed.

Matt
@mjy
@LocoDelAssembly should we be asking people to test new DwC Import changes you made?
Hernán Lucas Pereira
@LocoDelAssembly
Hold a bit. Doing additional tweaks before deploying to new sandbox for testing.
Matt
@mjy
Yup, no worires.