Hash lookup for Inat::Obs attributes

[JoeCohen]

• Uses hash lookup to access Inat::Obs attributes.
• Removes needless, repetitive pattern of defined methods.
  Ex: inat_obs[:id] instead of inat_obs.inat_id
• Fixes Inat::Obs class length metric offense.
• Responds to @mo-nathan suggestion.
• Replaces Inat::Obs class length #2416

There is no manual test.

[coveralls]

coverage: 93.453% (-0.003%) from 93.456%
when pulling fe066d5 on jdc-inat_obs-hash-lookup
into 8c9c794 on main.

[nimmolo]

Joe - I believe there is a better, more standard Railsy way to do all this, and there's an example on my PR:

Define your inat_obs as an ActiveModel::Model object, rather than a bare PORO.

This gives you the accessor methods without repetitive declarations, and potentially other goodies besides, like validation (although i didn't use that). You won't have to access your attributes by hash key. It makes it work like a model instance (because it is).

It's a "model not backed by a db table" and it's a very convenient thing. This is what people do for form data where the are assembling attributes that may go into some other model (like an observation, in your case) but they want the attributes of the form accessible like a model, too.

I've known about this for years but never understand quite how to use it, but now that I did, I realize how easy it is and will be using it elsewhere.

Check ObservationFilter at app/models/observation_filter.rb and NameFilter, which are based on a model SearchFilter that inherits from ActiveModel. It's at app/models/search_filter.rb.

class SearchFilter
  include ActiveModel::Model
  include ActiveModel::Attributes

  attribute :pattern, :string

[JoeCohen]

Thanks! Which pr has an example? Sent from Gmail Mobile El El sáb, sept 28, 2024 a la(s) 13:58, andrew nimmo < ***@***.***> escribió:

…

Joe - I believe there is a better, more standard Railsy way to do all this, and there's an example on my PR: Define your inat_obs as an activemodel object. This gives you the accessor methods without repetitive declarations, and other goodies besides. You won't have to access by hash key. It's a "model not backed by a db table" and it's a very convenient thing. — Reply to this email directly, view it on GitHub <#2418 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAALDFC2IIMMHPSQ47CD7ITZY4KBHAVCNFSM6AAAAABO2TV4ICVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGOBQHA4TGMRSG4> . You are receiving this because you were assigned.Message ID: ***@***.***>

[nimmolo]

#2337 — which as of yesterday does not require any migrations to check out, so it won't mess up your local db!

[JoeCohen]

@nimmolo: TLDR: I like the idea of a model not backed by a db table, but will postpone it till after NEMF.

1. I want a good window, before NEMF, for live shakedown tests of iNat import.
2. What I have now works, so I'd prefer to postpone refactors until after NEMF.
3. The hash stuff is convenient because it differentiates the raw iNat data from methods which manipulate or map that data. But that might indicate that Inat::Obs has too many concerns, and therefore that I should create another class. That's something that I certainly don't want to attempt prior to NEMF.
4. The hash stuff also works with all levels of the iNat data. I don't know about a model not backed by a db table, and don't want to take time right now find an answer.

Joe - I believe there is a better, more standard Railsy way to do all this, and there's an example on my PR:

Define your inat_obs as an ActiveModel::Model object, rather than a bare PORO.

This gives you the accessor methods without repetitive declarations, and potentially other goodies besides, like validation (although i didn't use that). You won't have to access your attributes by hash key. It makes it work like a model instance (because it is).

It's a "model not backed by a db table" and it's a very convenient thing. This is what people do for form data where the are assembling attributes that may go into some other model (like an observation, in your case) but they want the attributes of the form accessible like a model, too.

I've known about this for years but never understand quite how to use it, but now that I did, I realize how easy it is and will be using it elsewhere.

Check ObservationFilter at app/models/observation_filter.rb and NameFilter, which are based on a model SearchFilter that inherits from ActiveModel. It's at app/models/search_filter.rb.

class SearchFilter
  include ActiveModel::Model
  include ActiveModel::Attributes

  attribute :pattern, :string