Re: Issues with unique object IDs in persistence
Seamus MacRae wrote:
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? :)
Are you trying to claim that Derby takes a different footprint? Evidence?
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
Personal attack? I attacked the reasoning, not the person. The intentional
twisting of what I said was ridiculous. You knew if you had read the earlier
posts that I was using the term "embedded" the same way that Derby does in
their documentation.
admonished a bunch of comp.lang.lispers for exactly the same behavior.
"Admonished"? Say, rather, "goaded".
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.
Nonsense.
It pretty ambiguously means what it means in the context of the conversation,
in which I had already used the term to mean "embedded database application
within a Java application".
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".
Pardon me. Please understand that I assumed you would follow the context and
not twist it. I shall avoid that mistake. Rest assured I intended "embedded"
in the sense we'd already been using the term in this conversation, and not in
a new way.
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.
Projection. You asserted that the application would get "screwed up" and
would require "an uninstall/reinstall loop". Reading the Derby documentation,
to which I referred earlier, you will see that that isn't required with a
Derby-embedded application.
So tell me: Why do you think the DB would be bulletproof, uncorruptable
even by bugs in the client code?
I never said that I did think that. I said it was likely to be more stable
and easier to keep free of bugs than a custom disk-based solution. Don't put
words in my mouth. Your straw-man arguments are too transparent.
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.
Surely you read the post. He wants to "assign each object a unique ID of some
kind". You responded with advice about hash codes and a long, complex idea
for that association involving a custom disk solution.
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.
Except that none of that has to do with Derby.
There's no separate installation. There's no separate partition.
Apparently there's no actual database in this DBMS, then. How interesting.
Did you read the Derby documentation yet?
What are you on about?
The risks and headaches involved in repartitioning a hard disk. Haven't
you been paying attention?
Derby doesn't require that you repartition a disk. What are you on about?
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.
No personal jab. I commented on the speech, not the person.
Until something goes wrong.
Unless you honestly intend to make the outlandish claim that nothing
will ever, ever go wrong.
I've stated that that's not what I'm saying. Why would you read that into my
statements? I only said that the risk was lower than with a custom disk
solution, not that it was zero.
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.
It would be the application developer who fixes the problem with a
Derby-embedded system, not the user.
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.
And it would be the developer who fixes the Derby-embedded application, not a
sysadmin and not the user, same as with the disk-based solution.
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.
I never said any such thing. I said the application takes care of things
rather than the user. Stop straw-manning my arguments. It's intellectually
dishonest.
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?
They could have and should have.
"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.
Good thing I didn't say that, then.
Database: easier implementation, harder end-user servicing if it gets
corrupted or otherwise screwed up.
Normal disk files: harder implementation, easier end-user servicing.
That's backwards.
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.
Again with putting words in my mouth.
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.
the typical cop-out of the one whose point has been disproven. "You didn't
give evidence. Oh, wait, you gave evidence, but I refuse to look at it."
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.
Making the programmer's job easier reduces the risk of the programmer making
the user's life harder.
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
I think it would be easier to prevent bugs with a well thought-out, thoroughly
tested and robust system like Derby than with a brand-new complex custom
disk-based solution.
harder, and which ends up outweighing which, doesn't it? Which probably
Nope.
depends on the particular application, its nature and its user-base's
technical sophistication particularly. Which was my contention all along.
You bet on the solution you think will work better, and I'll bet on the one I
think will work better. Were I to implement a system that requires
association of persistent data, I'd use a database, and that's how I've gone
when faced with that decision. YMMV.
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? :)
Had you not been busy putting words in my mouth in order to "disprove" them,
you'd've seen that I've been talking about risks and probabilities all along,
not the absolutes that you've attributed to me. I speak of the type of
decision I've faced and made myself in my programming career. I don't think I
can make my points any stronger - the Derby documentation speaks for itself;
if you aren't too lazy to review it you will see that. Other embedded
databases exist; I'm not particularly partisan to Derby other than to note its
convenience as part of the standard Java distribution and good reputation over
its years of existence. Feel free to try a different solution in your
practice. I saw from your post upthread that you have the technical knowledge
to carry it off. I htink doing it the other way increases risk to your
customers and makes your programming job harder. You disagree. That's fair.
--
Lew