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

logger in module #16

Open
wants to merge 2 commits into
base: main
Choose a base branch
from
Open

logger in module #16

wants to merge 2 commits into from

Conversation

yzhoubk
Copy link
Contributor

@yzhoubk yzhoubk commented Dec 22, 2023

No description provided.

@yzhoubk
Copy link
Contributor Author

yzhoubk commented Dec 22, 2023

@danschmidt5189 In a module file, error messages not exporting to log, it turns out I have to move include Logging into the class block, or write logger with a namespace: Logging.logger.error("Failed to extract #{zip_file}: #{e.message}")

class << self
      include Logging
      attr_accessor :spatial_root, :geoserver_root, :processing_root
rescue Exception => e
        logger.error("Failed to extract #{zip_file}: #{e.message}")
        raise

@danschmidt5189
Copy link
Contributor

danschmidt5189 commented Dec 22, 2023

@yzhoubk Including the Logging module will add the logger method into whatever scope it was included. The behavior you're seeing is probably due to all of the DataHandler methods being defined on its class, i.e. in the class << self block. That's definitely not a "clean" way to write that code, but I'm not sure of the best method without diving into the refactoring myself. The easiest fix is (probably, haven't tested) to simply include Logging within the class block.

Edit: I just noticed your last comment, which echoes mine. I included the Logging module in the top-level simply because that's where Config (which used to also included Logging logic) was included. Do whatever works best.

The DataHandler module has quite a few code smells: why use a module rather than a class, given the state involved? If using a module, why put all the methods into the class block? Etc. But those are bigger than I think you want to handle here.

Copy link
Contributor

@danschmidt5189 danschmidt5189 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a good way to solve the immediate problem, so I'm +1 on merging it.

Overall, I think the DataHandler would benefit from being converted into a normal class rather than a module. It carries a lot of state and configuration information which is more naturally expressed via objects. A good goal would be to get it into a state where all of the logic currently expressed in the CLI methods, which handle the order of operations for ingestion, could be folded into this class (allowing us to call the method directly rather than shelling out). That can wait for a future refactoring.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants