On Fri, Sep 07, 2012 at 03:54:25PM +0200, Bo Maryniuk wrote: > > The /etc/rhn/rhn.conf has nothing to do with *Oracle* database at all.
Right, besides providing database type and connect information, which for Oracle backend turns out to be ... Oracle connection specification. :-P > has nothing to do with a particular database vendor. RHN configuration > is a place, where *generic* information about *any* database > connectivity is specified. Right. For Oracle, both I_AM_NAME_DEFINED_IN_TNSNAMES_ORA and //host.domain:1522/DATABASE_ON_THAT_HOST are valid strings that can be used in lieu of connect specification. Or database name if you will. > application. What if I am connecting my Windows Server .Net written > app over ODBC to Postgres? -- I am constructing my own URI inside. You have Spacewalk ported to .Net? > I can spot here severe logical problem: "We just leave them empty" ... for Oracle. If PostgreSQL had the same unified way of specifying the database connection target across all three stacks we use, we would not need db_host and db_port at all -- these were introduced specifically for PostgreSQL. The beautiful generic design of that configuration file had to give way to reality. > As a result, other components need to parse this URI, remove all the > host:port information and extract only a database name. Why? Why would they? All three stacks we use in Spacewalk use that db_name value directly, IIRC. No parsing needed. Why would Spacewalk care about the database name at all? Can you show the part of Spacewalk (code) where having the connect information stored this way (as opposed to creating and overriding /etc/tnsnames.ora which completely prevented people to have any advanced setups) poses a problem? > had a personal problem somewhere. In some cases it can be a different > syntax, like: > > user/password@//host:port/database > > or: > > (DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=host) > (PORT=port)))(CONNECT_DATA=(SERVER=DEDICATED) > (SERVICE_NAME=database)));User Id=user;Password=password; > > or: > > user/password@host/service:dedicated/database; > > or: > > //$host/$database?user=$user&password=$password&ssl=true It can. It might even work with the code as is. What's wrong with that? -- Jan Pazdziora Principal Software Engineer, Satellite Engineering, Red Hat _______________________________________________ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
