[
https://issues.apache.org/jira/browse/DERBY-4428?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kristian Waagan updated DERBY-4428:
-----------------------------------
Attachment: derby-4428-3a-canonical_name_handling.diff
Attaching patch 3a, which changes how StorageFactoryService handles canonical
names.
I have to admit the name handling puzzles me somewhat, but I hope I got it
right now. It seems that this code never expected to get canonical names from
other storage factories than the default. The value passed in will have the
storage factory type name, whereas the storage factory itself doesn't append
it's type. With the old code, every attempt to delete a service would fail,
except for when the default storage factory is used (the on-disk directory
based back end).
This patch caused me some trouble already, and I want to test it on Windows
before I commit it. An extra pair of eyes would be good as well!
So far the only errors observed have been assert errors, but I haven't verified
that everything works in insane mode despite the triggered asserts.
Patch ready for review.
> Add proper delete mechanism for in-memory databases
> ---------------------------------------------------
>
> Key: DERBY-4428
> URL: https://issues.apache.org/jira/browse/DERBY-4428
> Project: Derby
> Issue Type: Improvement
> Components: JDBC, Services, Store
> Affects Versions: 10.6.0.0
> Reporter: Kristian Waagan
> Assignee: Kristian Waagan
> Attachments: derby-4428-0a-preview_patch.diff,
> derby-4428-1a-in_memory_specific_delete_code.diff,
> derby-4428-1a-in_memory_specific_delete_code.stat,
> derby-4428-1b-in_memory_specific_delete_code.diff,
> derby-4428-2a-generic_db_drop.diff, derby-4428-3a-canonical_name_handling.diff
>
>
> The current mechanism for deleting in-memory databases isn't good enough, and
> a proper one must be added.
> It is also important to be able to delete in-memory databases, since they
> occupy valuable main memory that should be discarded when the database is no
> longer needed.
> I intend to implement the mechanism by using the JDBC connection URL:
> "jdbc:derby:memory:myDatabase;delete=true[;user=X;password=Y]
> The connection attempt will throw an exception in any case, either because
> the request failed or because it succeeded.
> Reasons for a failure can be invalid user and/or password, lacking encryption
> attributes, or conflicting attributes.
> For the time being, only the database owner will be allowed to delete
> databases (*note*: do we have a way to control/limit in-memory database
> creation?)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
