Re: Issues with unique object IDs in persistence

Lew wrote:
Seamus MacRae wrote:
A two-megabyte DBMS? That'll be the day.

That day is today. From the website:
Derby has a small footprint -- about 2 megabytes for the base engine and embedded JDBC driver.

Didn't your mother tell you not to believe everything you read on the web? :)

I would not tell a user to use regedit.

Well, you're telling application developers to design their applications so that their support organization will have to tell customers to do something like "Get to a C:\ prompt. Fire up DBFixulator and type in the following SQL queries..." (expected response: "What's a sea prompt?")

Nonsense. I'm not telling anyone anything of the sort.

Well, not in so many words, but it's an implication that follows naturally from the predictable sequence of events:

1. Programmer uses Derby.
2. Program winds up containing a bug.
3. At a customer deployment, program triggers bug.
4. Database gets b0rked.
5. Customer finds program stopped working properly.
6. Customer finds quitting and restarting it doesn't fix it.
7. Customer calls support...

I'm not sure which of the above you'd argue is implausible. 1 is your own advice. 2 is pretty much inevitable, like it or not, as is 3 given that 2 occurred. 4 is dependent on the nature of the bug, but it doesn't seem implausible. 5 follows from 2. 6 follows from 5, 4, and the database being nonvolatile. 7 is inevitable given 5 and 6.

The users should not be doing SQL queries on an embedded application.

Oh, now you're recommending a DBMS be used in an *embedded* application! I don't know about that, either. Set-top boxes already suffer quite heavily from "no user-serviceable parts inside", so it might not actually make things any worse there.

Not *that* kind of "embedded". Sheesh. Is your reasoning so weak, then?

There's no call for personal attacks here, especially when you just admonished a bunch of comp.lang.lispers for exactly the same behavior.

You said, and I quote, "an embedded application". That pretty unambiguously means the application runs in a dedicated appliance like a set-top box, to most programmers.

If you'd been paying attention, you'd've seen that I'm speaking of Derby being embedded in the Java application.

That would be an "embedded database" in an application that may, or may not, itself be embedded, rather than an "embedded application".

But I thought we were discussing desktop applications, which will get screwed up and users will want to be able to get them working again, preferably without losing any of their work and without the mess and time-wastage of an uninstall/reinstall loop.

I've already discussed how that is not a problem with Derby.

You've asserted, not discussed, this implausible claim. An actual argument to support it would be far more interesting than another random personal attacks.

So tell me: Why do you think the DB would be bulletproof, uncorruptable even by bugs in the client code?

Well, except that there are a few differences between the two that you neglected to address, owing to the differing storage formats.

My idea was basically to use serialized Java objects, probably in individual files. Likely a problem could be solved, if not by fixing, then by deleting a particular such file and the app recreating it.

Serialization has noted weaknesses, including not fulfilling the OP's need for assocation between objects, something that an RDBMS does innately.

What sort of association? If he just meant objects referencing other objects would go together, Java serialization does that already.

A database, on the other hand, typically takes the form of a B-tree represented who-knows-how and living on its own dedicated disk partition. It won't be mountable as NTFS or VFAT or whatever, and

Now you're ranting.

No, I'm calmly stating common-place and well-known facts about databases.

Ranting would be:

ARE YOU OUT OF YOUR COTTON-PICKING MIND?! HOW IS THE END USER SUPPOSED TO FIX ANYTHING NOW? OH, NOW YOU'VE ***REALLY*** DONE IT!!!!1!1!one

:)

There's no separate installation. There's no separate partition.

Apparently there's no actual database in this DBMS, then. How interesting.

probably won't even be visible in Explorer. The installer has to do the semi-dangerous job of repartitioning the customer's hard drive -- hope

Nope. It's all contained in the application.

Well, if the developer wants to go that route and have a truly standalone binary (that repartitions the host computer's hard drive when first run), I suppose they could do that instead.

they keep backups. If anything goes wrong, there's no apparent way for anyone short of an expert to get into there and make changes. The typical user that even learns of the partition might try reformatting it, probably with catastrophic consequences (even if they don't reformat the wrong partition by mistake).

What are you on about?

The risks and headaches involved in repartitioning a hard disk. Haven't you been paying attention?

The database will in effect have no user-serviceable parts inside. If anything gets wacko in it, the typical user's only realistic recourse will be the uninstall and reinstall the affected application. And then they lose whatever the database is used to store.

Same for the disk-based solution.

Somewhat, but maybe not as severely. See above.

The above was incoherent and irrelevant rambling.

Yes, it was; please try to be a bit more focused the next time you post. Heavier on the rational argumentation and lighter on the personal jabs, particularly, if you please.

Same for the disk-based solution. Only the disk-based solution has more risk of trouble.

I don't know. It does have more scope for non-geek end-user intervention, at least in that they can just click named-by-support or somehow-suspect files and press "delete" instead of find some obscure widget somewhere and type in "DELETE * FROM PROFILES1" or whatever.

Again, as stated, this is only something that the application deals with.

Until something goes wrong.

Unless you honestly intend to make the outlandish claim that nothing will ever, ever go wrong.

But try telling that to anyone who's ever had to muck about with the Windows registry, Firefox profiles, or pretty much anything else of that nature, based on instructions off some web site or read to them over the phone by tech support.

System administrators can be expected to be able to recover from such a thing, however.

System administrators are not the target market here.

That's what I was afraid of.

Wha...? You were the one who said it was bad that an application would need a sysadmin.

No, I said that if an application's target audience is sysadmins, it can get away with having a much more cryptic user interface and harder-to-fix problems that need more technical monkeying to correct than if it's target audience includes Uncle Bob and Aunt Mathilda.

(Examples: vi's user interface; .htaccess files for Apache)

Intermediate is the case where some features are only of interest to power users, or the whole program is.

(Examples: quake config files for power-gamers to tweak; POV-Ray scene files)

When the software is widely used by ordinary folk, there are problems when it isn't easy to fix things that go wrong.

(Example without problems: Notepad. It just works. And if it ever somehow fucks up one of your text files, you can try opening it in Wordpad or Editpad or whatever and they will read it; text is text.)

(Example with problems: The Windows registry. If that gets scrozzled, it typically means a long phone call to Microsoft tech support.)

Until something goes wrong.

And this is superior to the custom disk-based solution how?

See above.

The "above" didn't address how embedded Derby works, and therefore does not address the point.

Sure it did. You are the one who didn't address the point. When you aren't changing the subject to ease of implementation or my lack of specific knowledge about Derby, you're claiming the application magically takes care of everything.

If that were possible, wouldn't Microsoft have made Windows able to magically take care of the registry so that users never had to deal with it, ever?

"Nothing will go wrong", or "It will all work out somehow -- trust me", when asked how the user is to fix things when they go wrong, is not addressing the point. It is a cop-out.

And I'm saying that that is but one issue among several, and there's a tradeoff among them.

Tradeoffs that you have yet to mention.

I've mentioned it quite plainly. But I'll spell it out once again:

Database: easier implementation, harder end-user servicing if it gets
corrupted or otherwise screwed up.
Normal disk files: harder implementation, easier end-user servicing.

Your only response to that, besides lying by saying I never mentioned it, has been the incredibly dubious assertion that there will never be a need for end-user servicing. Maybe if it's a "hello, world" program. In which case a database, however "embedded", is way overkill.

Calling Derby "full-blown" or "heavyweight" is misleading. It's actually lighter weight and lower risk than trying to manage files oneself and still get the functionality needed for the application.

I'll believe that when I see it.

So why don't you take a look, then?

Sorry -- don't have the time tonight to download fifty megs or so of whosits and whatsits. Too many plates to keep spinning. Maybe tomorrow.

SQL queries are not an issue for the users - everything is handled by the application.

Except fixing things the application's bugs borked up but the application provides no UI to fix.

Again, a disk-based solution is not necessarily superior in this respect, and arguably it's easier to clean up with a robust, tested proven product like Derby than with a custom hack.

Easier for a technician to clean up, I'll grant you.

Easy for a user who can maybe find and delete a file by name in Explorer but wouldn't know SQL from the things harvesting nuts outside his window -- maybe not so much. :)

(Although the hardest hit will probably be the poor, the downtrodden, the rank-and-file technical support peons in their awful little call-center cubicles.)

Making the programmer's life easier isn't always good. In particular, whenever it means making the end-users' lives harder, it almost always isn't.

Except that it doesn't make the end user's life harder, it makes it easier, by reducing the risk of bugs.

If we accept your claim, there'd be fewer bugs, but harder for the user to recover from. It all boils down to how many fewer, and how much harder, and which ends up outweighing which, doesn't it? Which probably depends on the particular application, its nature and its user-base's technical sophistication particularly. Which was my contention all along.

Compared to low-level file manipulation that the programmer has to
re-invent, Derby is a lighter, safer, more powerful solution.

Maybe. Probably at least part of the time. Probably not 100% of the time.

At last we agree.

That was my opinion from the outset. Are you now telling me you've been violently *agreeing* with me the entire time? :)
.

Quantcast