Not sure if this is what you had in mind for posting, but here goes:
The problem I'm trying to solve is extensibility to other data sources
(contexts). You have JDBC to cover basic SQL for relational databases, but all
of the NoSQL datastores are somewhat different and thus handled separately.
That's to say, there is a method in DataContextFactory to get a data context
for MongoDB and another for CouchDB. Other NoSQL datastore would each have to
have their own implementation (and factory methods). This is somewhat (!)
unwieldy.
What I'm proposing is a more generic data context factory mechanism.
First of all, I would define an interface: DataContextFactory with several
signatures, something like these (the interface might be split into different
types according to which type was appropriate):
public abstract DataContext createCompositeDataContext(DataContext...
delegates); // this would be implemented in an abstract base class
And a subinterface FileDataContextFactory for dealing with files, such as a
Xml, CSV or Excel context:
public abstract DataContext createFileDataContext(File file, char
separatorChar, char quoteChar, String encoding); // implemented by, for example
a factory for CSV
public abstract DataContext createFileDataContext (File file, char
separatorChar, char quoteChar); // implemented by, for example a factory for CSV
public abstract DataContext createFileDataContext (File file,
Configuration configuration); // implemented by, for example a factory for CSV
public abstract DataContext createFileDataContext (File file); //
implemented by, for example a factory for CSV
public abstract DataContext createFileDataContext (File file,
InputStream stream); // implemented by, for example a factory for CSV
etc. etc.
And another subinterface JDBCContextFactory for dealing with JDBC connections
public abstract DataContext createJDBCDataContext(Connection
connection);
and another subinterface CredentialedDataContextFactory for dealing with other
client/server connections, such as Salesforce
public abstract DataContext createCredentialedDataContext(Credentials
credentials); // where Credentials encapsulates things like username, password,
etc.
and another subinterface NoSQLDataContextFactory for dealing with other
client/server connections that need a server specification, such as MongoDB
public abstract DataContext createNoSQLDataContext(Credentials
credentials, ServerSpecification server); // where Credentials encapsulates
things like username, password, etc.
etc. etc.
Second, I would create a (singleton) DataContextFactoryRegistry class with
signatures something like this:
registerDataContextFactory(Class<? Extends DataContextFactory>
factoryClass, ClassLoader dataContextClassLoader)
registerDataContextFactory(Class<? Extends DataContextFactory>
factoryClass, URI dataContextJar)
registerDataContextFactory(Class<? Extends DataContextFactory>
factoryClass) // uses the classLoader for the DataContextFactoryRegistry class
This design decouples the specific implementations of data context from the
base system and allows data contexts to be plugged in dynamically (or at
startup time).
Third-party implementations of DataContextFactory (whether contributed or not)
would simply implement the appropriate signatures, perhaps extending an
abstract base type.
Comments very welcome of course - and I would be happy to find that the
DataContextFactory was not the proper place to solve it and that there was
another pattern that was more appropriate.
Robin
-----Original Message-----
From: Kasper Sørensen (JIRA) [mailto:[email protected]]
Sent: Wednesday, September 11, 2013 2:59 PM
To: [email protected]
Subject: [jira] [Commented] (METAMODEL-27) Non-extensible DataContextFactory
[
https://issues.apache.org/jira/browse/METAMODEL-27?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13764626#comment-13764626
]
Kasper Sørensen commented on METAMODEL-27:
------------------------------------------
Hi there,
I think it would be nice to have this issue and METAMODEL-28 discussed on the
mailing lists. While reading the issues descriptions, I get the sense that
you're trying to solve another problem than that which the DataContextFactory
solves.
Could you please post a mail about the problem as you percieve it, and maybe
some sample or pseudo code of what you have in mind to solve it. I'd prefer
taking it this way because I sense that you have some great and relevant
points, but maybe the DCF isn't the proper place to solve it?
Kind regards,
Kasper
> Non-extensible DataContextFactory
> ---------------------------------
>
> Key: METAMODEL-27
> URL: https://issues.apache.org/jira/browse/METAMODEL-27
> Project: Metamodel
> Issue Type: Wish
> Reporter: Robin Hillyard
> Priority: Trivial
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> This is very trivial: developers cannot extend DataContextFactory because it
> has a private constructor, yet it is not marked final (nor should it be,
> IMO). The desired behavior (nobody can invoke the constructor) can also be
> satisfied by a protected constructor.
> However, this is really part of a greater architectural issue which I will
> write up separately under the name Pluggable Data Contexts.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
This e-mail, including attachments, may include confidential and/or
proprietary information, and may be used only by the person or entity
to which it is addressed. If the reader of this e-mail is not the intended
recipient or his or her authorized agent, the reader is hereby notified
that any dissemination, distribution or copying of this e-mail is
prohibited. If you have received this e-mail in error, please notify the
sender by replying to this message and delete this e-mail immediately.
