Skip to content

reorganize and add timeseries#93

Merged
Enovotny merged 2 commits into27-create-init-scriptfrom
evn_init_script_updates
Jan 14, 2026
Merged

reorganize and add timeseries#93
Enovotny merged 2 commits into27-create-init-scriptfrom
evn_init_script_updates

Conversation

@Enovotny
Copy link
Collaborator

reorganize in load functions

  • added load timeseries ids-add
  • moved locations to load location ids-all
  • moved location group load to load location ids-bygroup

@Enovotny Enovotny requested a review from krowvin January 13, 2026 20:37
Copy link
Collaborator

@krowvin krowvin left a comment

Choose a reason for hiding this comment

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

@Enovotny

Not going to block this if you feel it is sufficient. I did want to KEEP the target office to be able to cross store data for testing purposes. Not a deal breaker, but consider making that option opt-in and keeping it?

Otherwise we can merge to move forward, i'll finalize anything on my end and we can get the rest pulled into main prior to the workshop.

source_cda: str,
source_office: str,
target_cda: str,
target_office: str,
Copy link
Collaborator

Choose a reason for hiding this comment

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

I think we should keep a target office. I would like the option to be able to load data from one office to another.

Would you consider defaulting to the target office being the source office if the target office is not provided?

I think we can add a function/param to the target_office click option to default to the source office?


if verbose:
click.echo(
f"[load location group] source={source_cda} ({source_office}) -> target={target_cda} ({target_office})"
Copy link
Collaborator

Choose a reason for hiding this comment

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

Same as above

for loc in locations:
click.echo(
f"[dry-run] would store Location(name={loc.name}) to {target_cda} ({target_office})"
f"[dry-run] would store Location(name={loc.name}) to {target_cda} ({source_office})"
Copy link
Collaborator

Choose a reason for hiding this comment

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

same as above

)
return

if not target_api_key and os.getenv("CDA_API_KEY"):
Copy link
Collaborator

Choose a reason for hiding this comment

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

Assuming this is removed because we handle the logic at the click argument level? I think I added this because I was not getting an error. We may want to try running this without the key set now to confirm.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

I don't want a default to something that might be in environment variables. someone could accidently copy things into their production database if they run from the T7 and have those variable set. the user needs to purposely set the api key and urls.

Copy link
Collaborator

Choose a reason for hiding this comment

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

I only meant with target office because it appears you are removing it which means target would always be source?

)(f)
f = click.option(
"--target-office",
envvar="CDA_TARGET_OFFICE",
required=True,
help="Target office ID for writes.",
)(f)
f = click.option(
Copy link
Collaborator

Choose a reason for hiding this comment

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

Same as above, consider defaulting to source-office. Be able to cross load data.

Comment on lines +22 to +33
@timeseries.command(
"ids-all",
help="Copy ALL timeseries IDs for locations in a target CDA from a source CDA.",
)
@shared_source_target_options
@click.option(
"--timeseries-id-regex",
"timeseries_id_regex",
default=None,
type=str,
help="regex filter for timeseries ID (e.g. 'LocID.*').",
)
Copy link
Collaborator

Choose a reason for hiding this comment

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

I thought I had started work on this in my PR?

One of the issues I was running into was that it needed to load the locations to be able to load the timeseries IDs.

I may have been focusing more on groups though and not individually specified TSIDs?

"active": row["active_x"],
}
try:
result = cwms.store_timeseries_identifier(
Copy link
Collaborator

Choose a reason for hiding this comment

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

I mentioned needing the locations above. But I wonder if using the store_timeseries_identifier works differently then me doing a store_timeseries directly?

If so we'd want to go with your method! I did not realize the store_timeseries worked without at least a base location present. (even if the type is different)

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

no you have to do the location first. that is why I have a check to only load timeseries that have a location in the target database.

Copy link
Collaborator

Choose a reason for hiding this comment

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

Ah that must be the method you use for idenitfier. I do get 404 when I try with store_timeseries

@Enovotny
Copy link
Collaborator Author

@Enovotny

Not going to block this if you feel it is sufficient. I did want to KEEP the target office to be able to cross store data for testing purposes. Not a deal breaker, but consider making that option opt-in and keeping it?

Otherwise we can merge to move forward, i'll finalize anything on my end and we can get the rest pulled into main prior to the workshop.

you would need to update the json before loading since that would also have the office in it. I didn't see that being update so essentially the target office was not being used. I am not sure the use case either. the point is bulk loads from one database to anther not once office to another.

@krowvin
Copy link
Collaborator

krowvin commented Jan 13, 2026

That makes sense, im with you

You might remove source office too and just use existing office for both?

Or do you want to distinguish the office for loader purposes? I.e. something less likely to default from env?

If so might remove the env option altogether for the loader office?

@Enovotny Enovotny merged commit 51246b6 into 27-create-init-script Jan 14, 2026
3 checks passed
@Enovotny Enovotny deleted the evn_init_script_updates branch January 15, 2026 16:44
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