adfemg
  1. adfemg
  2. ADFEMG-101

[ADFng1-0207] Database Connection names

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Minor Minor
    • Resolution: Won't Fix
    • Labels:
      None

      Description

      Hi,

      "...start with the name of the database schema..."

      • What is when the database schema change, for migration, for upgrade, for different customers ?!
      • Should this not be a symbolic name like the alias in tnsnames.ora ?!
      • Maybe only the DBA/Admin knows which database schema is used.
      • What is with proxy user schema's (database user only with DML access)

      We use the codename of the project for the database connection name without any pre- or postfix.

      Sample namespace:

      enpit.<codename>[.<module>].<layer>......

      enpit.sapp.model
      enpit.sapp.contact.model

      codename := sapp

      So the main database connection is: sapp
      Is any module of the solution different database connection, so the name is the module: contact

      So we end up with two database connection pools in wls with the names:

      jdbs/sappDS
      jdbc/contactDS

      Only the WLS Admin / DBA knows which database schema is used.

      Different customers will be served on different wls managed servers.
      But with the same convention, so it is very easy to clone the env.

      Only the WLS Admin / DBA knows which database schema is used !

      with king regards,
      Ulrich Gerkmann-Bartels

        Activity

        Hide
        chriscmuir added a comment -

        Thanks for taking the time to log the issue Ulrich.

        This relates to issue ADFng1-02007 rather than 0207 as stated in the issue title.

        I'm going to point out here that you need to differentiate between the JNDI and the Database Connection names. These are separate rules (which you may choose to relate), but I deliberately didn't define the JNDI rules as I haven't seen enough customer examples to make a rule at this time.

        If I put aside database connections in assessing your points and just consider your concerns in terms of JNDIs, the benefit of a JNDI is indeed, they abstract away from the problems you've outlined here and a good set of rules here is beging. But database connections are something that developers work with, they do know the schema/account they connecting to, otherwise, how would they connect in the IDE?

        There are also a number of edge cases where defining a definitive set of rules for the database connection and even JNDIs becomes more "interesting". As the following blog describes (https://blogs.oracle.com/onesizedoesntfitall/entry/making_use_of_multiple_independent) it's possible for one model project to rely on more than one database connection. Obviously our naming scheme now needs to cater for 2 or more connections, but also naming collisions.

        This leaves me in a position wondering if a set of rules for database connections and separately JNDIs should consider every edgecase that 90% of customers wont encounter, or keep with a simple set of rules that will do in most cases.

        As the guidelines state:

        "Generally the guidelines should be followed but in the cases where it doesn't make sense to do so, where you have your own preference, certainly diverge from the guidelines. However ensure to document why and when this has occurred so your team follows a single guideline rather than an ambiguous set of conflicting guidelines from Oracle and your own efforts."

        Show
        chriscmuir added a comment - Thanks for taking the time to log the issue Ulrich. This relates to issue ADFng1-02007 rather than 0207 as stated in the issue title. I'm going to point out here that you need to differentiate between the JNDI and the Database Connection names. These are separate rules (which you may choose to relate), but I deliberately didn't define the JNDI rules as I haven't seen enough customer examples to make a rule at this time. If I put aside database connections in assessing your points and just consider your concerns in terms of JNDIs, the benefit of a JNDI is indeed, they abstract away from the problems you've outlined here and a good set of rules here is beging. But database connections are something that developers work with, they do know the schema/account they connecting to, otherwise, how would they connect in the IDE? There are also a number of edge cases where defining a definitive set of rules for the database connection and even JNDIs becomes more "interesting". As the following blog describes ( https://blogs.oracle.com/onesizedoesntfitall/entry/making_use_of_multiple_independent ) it's possible for one model project to rely on more than one database connection. Obviously our naming scheme now needs to cater for 2 or more connections, but also naming collisions. This leaves me in a position wondering if a set of rules for database connections and separately JNDIs should consider every edgecase that 90% of customers wont encounter, or keep with a simple set of rules that will do in most cases. As the guidelines state: "Generally the guidelines should be followed but in the cases where it doesn't make sense to do so, where you have your own preference, certainly diverge from the guidelines. However ensure to document why and when this has occurred so your team follows a single guideline rather than an ambiguous set of conflicting guidelines from Oracle and your own efforts."
        Hide
        Jan Vervecken added a comment -

        hi Ulrich

        The database connection names and the DataSource JNDI names seem to become less important if you consider using a deployment-plan to configure the "real DataSource JNDI name" at deploy-time.
        (Similar to what is discussed in forum thread "deploy given EAR file having application.xml and change context-root" [1], but for a DataSource instead of a context-root.)

        regards
        Jan Vervecken

        Show
        Jan Vervecken added a comment - hi Ulrich The database connection names and the DataSource JNDI names seem to become less important if you consider using a deployment-plan to configure the "real DataSource JNDI name" at deploy-time. (Similar to what is discussed in forum thread "deploy given EAR file having application.xml and change context-root" [1] , but for a DataSource instead of a context-root.) [1] https://forums.oracle.com/forums/thread.jspa?threadID=2467611 regards Jan Vervecken
        Hide
        chriscmuir added a comment -

        Unless there's a follow up comment with a convincing argument to change the current rule in the document, next time I revisit this issue I will close it as 'wont-fix'.

        CM.

        Show
        chriscmuir added a comment - Unless there's a follow up comment with a convincing argument to change the current rule in the document, next time I revisit this issue I will close it as 'wont-fix'. CM.
        Hide
        chriscmuir added a comment -

        See previous comment.

        Show
        chriscmuir added a comment - See previous comment.

          People

          • Assignee:
            Unassigned
            Reporter:
            Ulrich Gerkmann-Bartels
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: