cccs-eric commented on code in PR #886:
URL: https://github.com/apache/iceberg-python/pull/886#discussion_r1664857704


##########
mkdocs/docs/configuration.md:
##########
@@ -222,6 +222,12 @@ catalog:
     uri: sqlite:////tmp/pyiceberg.db
 ```
 
+| Key           | Example                                                      
| Default | Description                                                         
                                                                                
                                           |
+| ------------- | ------------------------------------------------------------ 
| ------- | 
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
 |
+| uri           | postgresql+psycopg2://username:password@localhost/mydatabase 
|         | SQLAlchemy backend URL for the catalog database (see [documentation 
for URL 
format](https://docs.sqlalchemy.org/en/20/core/engines.html#backend-specific-urls))
                                |
+| echo          | true                                                         
| false   | SQLAlchemy engine [echo 
param](https://docs.sqlalchemy.org/en/20/core/engines.html#sqlalchemy.create_engine.params.echo)
 to log all statements to the default log handler                      |
+| pool_pre_ping | true                                                         
| false   | SQLAlchemy engine [pool_pre_ping 
param](https://docs.sqlalchemy.org/en/20/core/engines.html#sqlalchemy.create_engine.params.pool_pre_ping)
 to test connections for liveness upon each checkout |

Review Comment:
   I understand your point of view, and I'm not against it.  But here is mine 
for what it is worth 😜 
   
   I voluntarily kept the same name as SQLAlchemy thinking that eventually, 
SQLCatalog would support a pass-through to set the kwargs of `create_engine()`. 
 The first time, it was `echo`, this time is `pool_pre_ping`, will there be 
another case in a couple of weeks where we'll need another PR to fix a new 
issue needing another arg to be set?  
   
   So if the plan is to eventually adopt such a pass-through, I would vote for 
using the same name as SQLAlchemy, even though it goes against pyiceberg's 
convention.  
   On the opposite, if the idea is to always have pyiceberg be in control of 
the supplied properties, then it makes sense to enforce the convention and 
rename this property.



-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscr...@iceberg.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@iceberg.apache.org
For additional commands, e-mail: issues-h...@iceberg.apache.org

Reply via email to