db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dibyendu Majumdar (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DERBY-3351) Implement a Pluggable Storage Engine Architecture in Derby
Date Fri, 25 Jan 2008 23:04:35 GMT

    [ 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.


Mime
View raw message