yes, the issue with the comments is fixed.
Also git is working nicely - my question was not related to git usage itself but on how go get the git info into the logs. I was not sure if additional configuration is needed but obvoiusly it is not - very nice!
Time to drop shell scripts and bteq from your set of tools and switch to this python devops based approach. Everybody should be encourage to fork the lib on github and extend it!
When i try run Example 1 - HelloWorld.py , i receive an error :(
Import successfully compelted
Traceback (most recent call last):
File "C:/Users/avurbano/Documents/Work/python/teradata.py", line 1, in <module>
File "C:\Users\avurbano\Documents\Work\python\teradata.py", line 4, in <module>
udaExec = teradata.UdaExec(appName="HelloWorld", version="1.0", logConsole=False)
AttributeError: 'module' object has no attribute 'UdaExec'
Module installation completed without errors, code completion works fine and show method udaExec.
@overcaster - I believe the problem is that you are naming your script "teradata.py". This conflicts with the namespace of the Teradata Python Module. Therefore, your script is looking for UdaExec class in your script and not in the Teradata Python Module. Renaming your script to something else should fix the problem.
Yes, you absolutеly right :) Looks all works fine, problems only under Linux. I think problem with ODBC driver. But under Windows all work fine.
I want to log the output of an query into the application log.
" If you create a logger in your script, your custom log messages will also be logged along with the UdaExec log messages." - I tried it but didn't get it working. Might be a very basic mistake I make. Can you share an example how to add own log messages to the application log?
And one additional requirement - not sure how to best solve it.
In case I write a generic application - e.g. to copy a table from one DB to a new DB (just as an example) - the application name would be static. But each call for different tables would need a different checkpoint file to avoid conflicts between different runs of the same applications for different tables. I solved this right now by adding a hash of the configuration file name to the application name but I thing an additional parameter like instance would be better. And additing this instance to the checkpoint file name. Just some thoughts...
Solved the logging issue :-)
logger = logging.getLogger(__name__)
rc = 0
for row in session.execute("""
MY SELECT which should return 0 rows for being correct for further processing
rc += 1
if rc == 0:
udaExec.checkpoint("Step 5 Complete")
logger.error("ERROR - new and old table structure are different")
@ulrich - Glad you were able to get logging working. You can change the name of the checkpoint file easily enough without changing the name of the application. The UdaExec constructor takes a checkpointFile name argument either via the constructor or from the external configuration file. Here's an example:
Can the Working Dir be configiured?
No parameter is specified for this.
As this holds the checkpoint files some admins might prefer not use the source code file dir for this.
First generic job is ready and tested. I learned a lot about the module and how to use it. Really nice package!