[
https://issues.apache.org/jira/browse/DERBY-3351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12562741#action_12562741
]
Dibyendu Majumdar commented on DERBY-3351:
------------------------------------------
Regarding Storage Engine Boundary:
Obviously org.apache.derby.iapi.store.* and org.apache.derby.impl.store.* fall
within the Store boundary.
There are a number of packages in org.apache.derby.iapi.services that the store
depends upon.
Should these packages be part of the Store API - to be used by SQL and other
layers?
I am thinking of io, context, monitor, sanity, locks, etc.
The dictionary is not referenced by the Store it seems, but the Store does know
about Row types.
Should at least part of the dictionary be within the Store boundary?
Types should probably also be within the Store boundary.
I scanned the Store unit tests and extracted the import statements to see which
packages are used.
Given below is the list.
org.apache.derby.catalog.UUID;
org.apache.derby.iapi.error.ExceptionSeverity;
org.apache.derby.iapi.error.StandardException;
org.apache.derby.iapi.reference.Attribute;
org.apache.derby.iapi.reference.EngineType;
org.apache.derby.iapi.reference.Property;
org.apache.derby.iapi.reference.SQLState;
org.apache.derby.iapi.services.context.ContextManager;
org.apache.derby.iapi.services.context.ContextService;
org.apache.derby.iapi.services.daemon.DaemonService;
org.apache.derby.iapi.services.i18n.MessageService;
org.apache.derby.iapi.services.io.DynamicByteArrayOutputStream;
org.apache.derby.iapi.services.io.FormatIdOutputStream;
org.apache.derby.iapi.services.io.FormatIdUtil;
org.apache.derby.iapi.services.io.Formatable;
org.apache.derby.iapi.services.io.FormatableBitSet;
org.apache.derby.iapi.services.io.LimitObjectInput;
org.apache.derby.iapi.services.io.Storable;
org.apache.derby.iapi.services.io.StoredFormatIds;
org.apache.derby.iapi.services.locks.*;
org.apache.derby.iapi.services.monitor.ModuleFactory;
org.apache.derby.iapi.services.monitor.Monitor;
org.apache.derby.iapi.services.property.PropertyUtil;
org.apache.derby.iapi.services.sanity.SanityManager;
org.apache.derby.iapi.services.stream.HeaderPrintWriter;
org.apache.derby.iapi.services.uuid.UUIDFactory;
org.apache.derby.iapi.store.access.*;
org.apache.derby.iapi.store.access.conglomerate.LogicalUndo;
org.apache.derby.iapi.store.access.conglomerate.TransactionManager;
org.apache.derby.iapi.store.access.xa.*;
org.apache.derby.iapi.store.raw.*;
org.apache.derby.iapi.store.raw.data.RawContainerHandle;
org.apache.derby.iapi.store.raw.log.LogInstant;
org.apache.derby.iapi.store.raw.xact.RawTransaction;
org.apache.derby.iapi.types.CloneableObject;
org.apache.derby.iapi.types.DataValueDescriptor;
org.apache.derby.iapi.types.Orderable;
org.apache.derby.iapi.types.RowLocation;
org.apache.derby.iapi.types.SQLChar;
org.apache.derby.iapi.types.SQLInteger;
org.apache.derby.iapi.types.SQLLongint;
org.apache.derby.iapi.types.StringDataValue;
org.apache.derby.iapi.util.ByteArray;
org.apache.derby.impl.store.access.btree.BTree;
org.apache.derby.impl.store.access.btree.index.*;
org.apache.derby.impl.store.access.conglomerate.*;
org.apache.derby.impl.store.access.conglomerate.TemplateRow;
org.apache.derby.impl.store.access.heap.*;
org.apache.derby.impl.store.raw.data.*;
org.apache.derby.impl.store.raw.log.*;
org.apache.derby.impl.store.raw.log.LogCounter;
org.apache.derby.io.StorageRandomAccessFile;
> Implement a Pluggable Storage Engine Architecture in Derby
> ----------------------------------------------------------
>
> Key: DERBY-3351
> URL: https://issues.apache.org/jira/browse/DERBY-3351
> Project: Derby
> Issue Type: New Feature
> Components: Services, SQL, Store
> Reporter: Dibyendu Majumdar
> Assignee: Dibyendu Majumdar
>
> My aim is to create a pluggable storage engine architecture for Derby, so
> that the default store implementation can be replaced with alternative
> storage engines. I have created my own storage engine which I would like to
> use with Derby's SQL layer, so that is a motivation. But I also think that
> this will benefit the community, and could lead to a pluggable storage engine
> architecture similar to that of MySQL.
> I am not yet sure where the storage engine boundary should lie. I would
> welcome input in this area.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
