search

MushroomObserver / mushroom-observer

A website for sharing observations of mushrooms.
https://mushroomobserver.org
MIT License
81 stars 26 forks source link

Change iNat Import Manager #2284

Open JoeCohen opened 3 months ago

JoeCohen commented 3 months ago

Change the User which owns special objects created during iNat imports (e.g., Namings not first proposed by the User who is doing the import; the iNat data comment)

Tasks

nimmolo commented 3 months ago

Are these "users" going to stick around in the db?

I'm sure you've thought about it, but bringing in namings and ALSO phantom users, it sounds like a lot of junk data.

Only having thought about it this minute admittedly, I'd lean towards attributing all the "objects coming from iNat imports that do not belong to the importing User" to a single all-purpose "other iNat User", unless you think these phantoms could eventually be "rehydrated" into real MO users, for example if the original object owner ALSO signs up with MO.

JoeCohen commented 3 months ago

@nimmolo Great questions.

  1. There will only ever be one such user, so I'm not worried about proliferation of phantom users.
  2. I don't regard the Namings are junk data. They are as useful for Observations imported from iNat as for any other MO Observation. NOTE: I think there should be at least one Naming per imported Observation. (Else the Observation has a Name without a Naming, which seems weird and might have unanticipated side-effects.) The (initial) MO Observation.name corresponds to the iNat Community Taxon. iNat may not have an identification which corresponds to the Community Taxon. So I think I should associate an MO user with that. (Ex: iNat obs has 2 identifications: Russula brevipes and R. cascadensis. The iNat Community ID will be Russula, even though no iNat user has suggested that Name.) Also, for each iNat import I'm creating an initial Comment that summarizes the state of the iNat obs. I don't want that Comment to belong to the User who created the import (because I don't want that User to be able to modify that Comment.)
  3. IMO it's too complicated to later change the object owner to an MO user.
nimmolo commented 3 months ago

Sounds good. # 1 seems to answer it, i didn't notice how the user was being used.

(I didn't mean to imply the Namings were junk data, but that the Naming users were potentially junk data, if there was a new mystery user created for each Naming.)

JoeCohen commented 3 months ago

@nimmolo I'm happy to consider different ways of doing this.

nimmolo commented 3 months ago

Well, when you say "there will only ever be one such user" do you mean that you'll create one all-purpose "iNat user" who will be the attributed user for all the Namings not attributed to the importing User? If that's how you're doing it, that seems ideal.

It's creating a new fake user for each imported Naming [not proposed by the importing User] that would be my concern - potentially many thousands of fake Users for each power user whose data we import.

We query the User table all the time, often with wasteful duplicate queries, and doubling the size of the User table would be my junk data scenario, and carry a performance penalty.

JoeCohen commented 3 months ago

i mean the former. one iser resposible for all the imports.

Sent from Gmail Mobile

El El sáb, ago 3, 2024 a la(s) 17:48, andrew nimmo @.***> escribió:

Well, when you say "there will only ever be one such user" do you mean that you'll create one all-purpose "iNat user" who will be the attributed user for all the Namings not attributed to the importing User? If that's how you're doing it, that seems ideal.

It's creating a new fake user for each imported Naming [not proposed by the importing User] that would be my concern - potentially many thousands of fake Users for each power user whose data we import.

We query the User table all the time, often with wasteful duplicate queries, and doubling the size of the User table would be my junk data scenario, and carry a performance penalty.

— Reply to this email directly, view it on GitHub https://github.com/MushroomObserver/mushroom-observer/issues/2284#issuecomment-2267221713, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAALDFG43RODZVX2I5UYXCTZPV26FAVCNFSM6AAAAABL54HRLWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDENRXGIZDCNZRGM . You are receiving this because you modified the open/close state.Message ID: @.***>