Remove hardcored SRS

[lbartoletti]

For the moment, it is not possible to pass variables to pum. While waiting for an evolution of pum, I propose to get the SRID from the database. This is only one way among many to achieve this workaround. There are others.

[ponceta]

LGTM, @3nids thoughts?

@lbartoletti fix https://github.com/qwat/qwat-data-model/issues/199 right?

[3nids]

PUM 0.8.0 now accepts variables in Python deltas

[lbartoletti]

@3nids Thanks. I will use this new feature.

[lbartoletti]

@3nids Hmm. Printing args in pum, returns: Namespace(command='test-and-upgrade', config_file=None, dir=['./update/delta/', '/tmp/delta/'], exclude_schema=None, file='/tmp/qwat_dump', ignore=['views', 'rules'], max_version=None, pg_service_comp='qwat_comp', pg_service_prod='qwat_prod', pg_service_test='qwat_test', table='qwat_sys.info', var=None, version=False, x=False)

Any idea?

[3nids]

How did you get that?

The command has not change for test-and-upgrade (--variables arg) Look at the readme, it's all documented.

[lbartoletti]

How did you get that? I changed a line in PUM to debug it:

if args.command in ('upgrade', 'test-and-upgrade'):
print(args.var, args, type(args.var))

The command has not change for test-and-upgrade (--variables arg) -v, --var

Look at the readme, it's all documented.

Of course, I read it, maybe I missed something. Also, for information, self.variables (in post-all.py for example) returns 'RecreateViewsAndFunctions' object has no attribute 'variables'

[3nids]

Also, for information, self.variables (in post-all.py for example) returns 'RecreateViewsAndFunctions' object has no attribute 'variables'

you might have tested just in the mean time of the release. In former versions, only self.variable(name) was available. The whole dictionary self.variables is only available with the last version (0.8.2).

I changed a line in PUM to debug it: it's indeed in the Namespace, the variables are in var (None in your case)

[lbartoletti]

Also, for information, self.variables (in post-all.py for example) returns 'RecreateViewsAndFunctions' object has no attribute 'variables'

you might have tested just in the mean time of the release. In former versions, only self.variable(name) was available. The whole dictionary self.variables is only available with the last version (0.8.2).

Right.

I changed a line in PUM to debug it: it's indeed in the Namespace, the variables are in var (None in your case)

Normally, I have a variable "SRID" with this line: pum test-and-upgrade -x -pp qwat_prod -pt qwat_test -pc qwat_comp -t qwat_sys.info -d ${DELTADIRS[*]} -f $TMPFILEDUMP -i views rules -v int SRID $SRID Isn't it? So It shouldn't be None and variables must have an element.

[lbartoletti]

@3nids sees https://travis-ci.org/qwat/qwat-data-model/builds/523837383#L2986

[3nids]

You can look at the last PR in QGEP datamodel, it uses this functionality.

[3nids]

In the post-all too

[lbartoletti]

@3nids AFAIK, I use it in the same ways, but variables is always empty.

[3nids]

Can you try self.variable('SRID'), this should raise an exception if not found.

Are you sure SRID is there in bash? Can you try hardcoring it in the command line?

[3nids]

And...maybe try with the long version of the param (--)?

[lbartoletti]

Can you try self.variable('SRID'), this should raise an exception if not found.

https://github.com/qwat/qwat-data-model/pull/298/files#diff-d61f136ed61eaa6eb14ec407a21e2b64R183

returns https://travis-ci.org/qwat/qwat-data-model/builds/523837383#L2987

Are you sure SRID is there in bash?

Yes, https://github.com/qwat/qwat-data-model/blob/master/update/upgrade_db.sh#L19 and used after.

Can you try hardcoring it in the command line?

Already tried :/

And...maybe try with the long version of the param (--)?

Already tried too.

[3nids]

really strange. It does work on QGEP see https://github.com/QGEP/datamodel/pull/95/files#diff-e64986a6710872bdf030617dfe01abc4R25 the argument is mandatory, and it passes. It's called from here https://github.com/QGEP/datamodel/pull/95/files#diff-11c23a617fc0061c004d90b2bf5fad11R21

A workaround in your case, would be to use environment variables.

[3nids]

I added a test in PUM, and it is working as expected. see https://github.com/opengisch/pum/pull/55

[lbartoletti]

@3nids arguments are not taken by pum, maybe a bug with the parser.

@ponceta I reverted my commits with pum, so it's my first workaround. A better approach - with pum - is still needed.