Re: Issues with unique object IDs in persistence
Lew wrote:
The data stored is the largest part of the disk overhead, which would
be true for the other disk-based solution, too, of course. Derby
itself only adds 2 MB to the footprint - not much at all.
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.
What, you thought I'd make such a specific claim out of the blue? Come on.
Seamus MacRae wrote:
I was using the Windows registry as an analogy. Fixing a problem in
the application's database and fixing a Windows registry problem
would probably be equally hard. The registry is probably easier: at
least Windows comes with regedit, which is a GUI app, and the Windows
registry is so ubiquitous lots of web sites provide technical
information about
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. Don't misstate my
point in an attempt to refute it; that just shows weakness in your points.
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?
If you'd been paying attention, you'd've seen that I'm speaking of Derby being
embedded in the Java application. Stop misstating my points; it just shows
the weakness in yours.
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.
Also, the comparison is between Derby, a simple database solution, and
a custom-written disk-based solution that has to deal with many of the
same troubles that Derby has already handled for you. In this
comparison, I'd lay odds that Derby wins.
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.
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. Have you even bothered to learn what Derby is?
There's no separate installation. There's no separate partition. There's
none of the nonsense that you're spouting.
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.
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 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.
It may have its uses, but it's probably overkill for just storing
window positions and other state like that, and for anything it's not
overkill for, using it means users can easily lose years of work if
something goes wrong.
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. The
user, in an embedded-database application (NOT a set-top box, silly), never
deals with this.
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. I'm only pointing out that your concern is addressed with the
solution I propose.
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.
the problem is that a custom solution carries much risk. Bugs
happen. A tested, mature product with a small footprint that has
already weathered those storms reduces the risk.
As a side effect, you can't delete a corrupted "file" from it without
knowing "DELETE * FROM X" or similar, and also knowing where to put it
in. It's bad enough most users can't find the Documents and
Settings/Application Data directory where the files will probably be
that need deleting in the normal-disk-files case.
Implementation simplicity isn't the issue above.
I am saying that it is, along with maintenance simplicity and reduced
risks of bugs.
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.
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?
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.
The programmer's life is easier because Derby gives the necessary
functionality.
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.
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.
--
Lew