Valid JDBC url syntax/format question

[Steven Squeers]

Hi

OK so this is a question from the Sybex bank:

Which of the following is a valid JDBC URL?

A.	jdbc:oracle:123.123.123.123
B.	jdbc:oracle:thin:123.123.123.123
C.	jdbc:oracle:thin:123.123.123.123//fun
D.	oracle:jdbc:123.123.123.123
E.	oracle:jdbc:thin:123.123.123.123
F.	oracle:jdbc:thin:123.123.123.123//fun

           

I have seen a few of these questions now and I am quite worried that one of them is going to pop up on the exam. All I've seen in the book is that the url has to be:
jdbc:dbname_or_vendor:some_other_unspecified_stuff

The documentation for DriverManager.getConnection states the same, more or less:

url - a database url of the form jdbc:subprotocol:subname

So given that, how are we supposed to decide which of A,B and C is the "correct" answer? It gets worse because the given answer is:

         
A JDBC URL must begin with JDBC, making choices D, E, and F incorrect. The database name is required, making choices A and B incorrect. Therefore the answer is C.

It looks to me like A,B and C all have oracle in the name. All of them seem to conform to "a database url of the form jdbc:subprotocol:subname"

Can anybody shed any light on this murky area?  Thank you very much in advance.

[Ankit Garg]

I don't think for the exam you'll need to know syntax of JDBC connection for Oracle (even though Oracle controls the certification )

[Tim Holloway]

I think your "given answer" is questionable, and frankly, I'm a little sceptical about the model URLs given one and all.

JDBC URLs conform to RFC Uniform Resource Identifier syntax.

The first element of a URI/URL is the protocol: "jdbc:" (contrast with "http:" for the web)
The second element is, in the case of JDBC, the driver class. That is the vendor name, which in this case is "oracle".
Oracle has done several different drivers, so the third element tells which one to use - the "thin" driver, instead of, say, "oci8".

Now we get to the questionable point. Next up should normally be the server ID - hostname or IP address (123.123.123.123). And right here we get to the reason why I despise certification exams. First, because a well-run shop shouldn't be using hard-coded server IDs, it should be using logical domain hostnames. So instead of an IP address, I use a form more like "jdbc: oracle:thin@proddb". And note the "@". Oracle's preferred form is user/password@host, although if you want to make it harder to snoop, you can do just "@host" and provide the user ID and password out of sight. Presumably the "@" can be omitted and inferred as meaning the host, optionally followed by the port ID, since a machine may host multiple instances, each listening to unique ports. Then following the host, you have the database name or TNSNAME of the database. Incidentally, the space before the "oracle" is bogus and only intended to keep our editor from making a smiley out of it.

But while Oracle may be popular, it's also weird. The more common syntax looks like "jdbc:driver://host:port/dbname", where port and dbname are often optional. That's the syntax used by, for example, mysql and IBM's DB2.

In any case, the "//fun" part doesn't match anything I've ever seen. It's syntactically valid, but I have no idea what it's trying to do, and in any event, it would have to be something obscurely Oracle-specific.

A plague on test-makers who think that asking clever tricksy questions somehow determines how qualified you are to actually do a job.  

[Steven Squeers]

Hi Tim
Thanks for taking the time answer my question. I think what you say re the legal formats in practice is all absolutely true; the trouble is the question doesn't seem to be concerned with any of it.

FWIW I do think though that you're in danger of throwing the baby out with the bath water re the certs. What they do, especially for less experienced and newbie developers like myself, is force us to learn a *lot* of stuff quite deeply that we would almost certainly never have got round to learning ourselves; yes everyone learns on the job but I do feel that it's questions like this one that possibly give the wrong impression as to how useful the exams can be for ensuring decent foundational knowledge and competence in core java for newer developers.  

If you're not a practising, professional java developer, and especially if you're just learning java from scratch, these exams are pretty tough stuff.

Cheers
SS

[Jeanne Boyarsky]

Steven,
I'm sure you read our rant in the chapter about what Scott and I think about the database topic coverage on the exam.

That said, you do not have to know the Oracle driver syntax on the exam. We used Oracle as the name in the example for the sake of picking something. What you do need to know is the simplified database url syntax. Knowing jdbc comes first and that a database name needs to be included is not memorizing the syntax. A and B don't have a database name at all.

[Tim Holloway]

Steven, my big gripe with certs is that they obsess on stuff that everyday users don't deal with. Or when we do, we track down the bastard that did it and try and choke them. For example, I know that Java has an extensive and fine-grained assertion mechanism. But if I need to use it, I'll look up the details because fine-grained JVM-level assertions are something I don't think I've ever been desperate enough to use. And when I do, the fine details I learned may be out of date.

In fact, my fame has rested in large part not on what I know directly but rather on being able to locate what I need to know quickly. Before Google, we had long racks of paper manuals, and I used to annoy people by being able to not only the right book, but be able to open it almost directly on the right page.

Fundamental knowledge is essential, don't think otherwise. But I'll refer you to Sherlock Holme's statement on what he kept in his mental "library" and what he kept in his "lumber room" (or attic, for Americans). Too many cert exams aren't even devoted to trees, but to individual leaves, and completely lose the forest. And too many people cram-and-barf and forget on cert exams. A good set of textbooks well-studied and a perusing of places like github will do much better.

In fact, the only 2 certs I really respected were the Red Hat RHCE and the Cisco CCNA, both of which set you up in a real-world situation and made you solve real-world problems in real time. But it's very hard to do that with software. Most software of any complexity is going to take days to design and code. For that matter, more than once I've lost 2 days just tracking down a wayward comma.

I'm going to have to disagree somewhat with Jean on JDBC URLs, though, and here's why:

Real-world database terminology is kind of sloppy. There are 4 primary levels to consider:

1. The host machine (physical box or VM)
2. The database server instance. Many DBMSs can have more than one instance running simultaneously on the same host
3. The "database" itself. This is where things get sloppy. In some cases, the database and the instance are the same thing. In others, an instance may contain multiple entities called "databases". It's been a while, but I'm pretty sure that the Oracle 8 servers I used to work with didn't distinguish between a database instance and the database.
4. A database schema. Here again, things can be sloppy. In Oracle 8, as I said, I think that there was no "database" object, but we worked with schema objects. Conversely the concept of a schema as a sub-element of a database object was a late arrival to MySQL and PostgreSQL. On the last DB2 server I worked with, a userid was associated with a default schema, and here again my separate "databases" were separate DB2 instances on the same server host. Their URLs had different port numbers.

And if that wasn't messy enough, Microsoft SQL server also has an organization group called "owner" that can factor in and make life miserable.

So a JDBC URL may or may not contain a "database name" either in the URI or an associated query string. In some cases, the "database" selected is determined by what credentials you attach with.

[Steven Squeers]

Jeanne Boyarsky wrote:Steven,
I'm sure you read our rant in the chapter about what Scott and I think about the database topic coverage on the exam.

That said, you do not have to know the Oracle driver syntax on the exam. We used Oracle as the name in the example for the sake of picking something. What you do need to know is the simplified database url syntax. Knowing jdbc comes first and that a database name needs to be included is not memorizing the syntax. A and B don't have a database name at all.

Hi Jeanne
Thank you for your reply, and sorry for my delay in replying; I've been buried in my OCP studying and mock exams.
You said that A and B don't have a database name, but they all have a database name:

A.  jdbc:oracle:123.123.123.123
B.  jdbc:oracle:thin:123.123.123.123
C.  jdbc:oracle:thin:123.123.123.123//fun

[Steven Squeers]

I see now what you mean; oracle is the name of the database vendor, but, not the name of the database in this context; the db name (which might be an sid or servicename in oracleland) follows the port, typically like this

jdbc:oracle:thin:scott/pa55w0rd@localhost:1521/orcl

"

[Jeanne Boyarsky]

Right,
We picked Oracle as the example database vendor because everyone's heard of it. Or nearly everyone! And even if they don't know Oracle has a database, they would know Oracle is a company.

[Edmund Yong]

In the book Oracle Certified Professional Java SE11 Programmer II by Scott Selikoff and Jeanne Boyarsky, page 538 on JDBC, the following URL is listed as a valid one:

jdbc:mysql://localhost:3306

For this URL, there is no database indicated.

[Tim Holloway]

Edmund Yong wrote:In the book Oracle Certified Professional Java SE11 Programmer II by Scott Selikoff and Jeanne Boyarsky, page 538 on JDBC, the following URL is listed as a valid one:

jdbc:mysql://localhost:3306

For this URL, there is no database indicated.

Yes, I think that's probably an error. But please report it as a separate posting or your report may get overlooked. In fact, I would verify that this forum is where Scott and Jean talk about their books, because offhand, I'm not sure that they don't do that in some other forum.

[Jeanne Boyarsky]

That's actually legal.

The MySql docs say

If the database is not specified, the connection is made with no default database.

So not common, but it can happen.

We were trying to show that you shouldn't get too attached to the format for the later part of the string. You have to know that it starts with jdbc, has the db type (ex: mysql) and is colon delimited.

[Edmund Yong]

Jeanne Boyarsky wrote:
We were trying to show that you shouldn't get too attached to the format for the later part of the string. You have to know that it starts with jdbc, has the db type (ex: mysql) and is colon delimited.

Then the following three should all be valid answers. After all, unless you are familiar with Oracle, you wouldn't know whether the database name is required or not.

jdbc:oracle:123.123.123.123
jdbc:oracle:thin:123.123.123.123
jdbc:oracle:thin:123.123.123.123//fun

[Tim Holloway]

Edmund Yong wrote:
Then the following three should all be valid answers. After all, unless you are familiar with Oracle, you wouldn't know whether the database name is required or not.

And for that matter, whether it actually is the database name or a TNAME. I haven't checked lately, but despite TNAMEs being supposedly deprecated way back around Oracle 8, I think they were still supported up until at least Oracle 10 and possibly beyond.

A JDBC URL doesn't actually care what the context part refers to - database name, TNAME, namespace, schema, whatever. It's whatever the driver implementor wished to support. All that matters is that it conform to the lexical rules defined in the RFC for URL's.