metamodel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hillyard, Robin C" <>
Subject RE: [jira] [Commented] (METAMODEL-27) Non-extensible DataContextFactory
Date Thu, 12 Sep 2013 18:35:41 GMT
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

	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

	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

	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.


-----Original Message-----
From: Kasper Sørensen (JIRA) [] 
Sent: Wednesday, September 11, 2013 2:59 PM
Subject: [jira] [Commented] (METAMODEL-27) Non-extensible DataContextFactory


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,
> Non-extensible DataContextFactory
> ---------------------------------
>                 Key: METAMODEL-27
>                 URL:
>             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:

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.
View raw message