metamodel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kasper Sørensen <>
Subject Re: [jira] [Commented] (METAMODEL-27) Non-extensible DataContextFactory
Date Thu, 12 Sep 2013 19:25:28 GMT
I think I see what you are getting to, and probably the solution you sketch
would work.

But I am not sure if it is really needed. In fact, as things are today, you
can simply just use the constructors of the individual DataContext
implementations. The role (today) of the DataContextFactory is in that
sense not to provide a extensible/pluggable factory framework, but simply
to provide a handy set of pointers to the different types of DataContexts
you can create out of the box. In many cases though, I don't use the
factory but just use the constructor of whatever DataContext implementation
I need.

On the other hand, you idea got me thinking about a common issue I have
seen time and time again: That the constructors make instantiation a bit
unhandy in e.g. Spring XML files, where you don't have any getter/setter
based initializations or any spring FactoryBeans or anything like that. I
could imagine a generic DataContextFactoryBean which would allow the
developer to specify DataContext type and configuration options as
properties, and then have the FactoryBean use those properties to construct
a proper DataContext. Sorry if this is hijacking your mail thread and
turning it into another type of solution... Just wanted to ask: Would this
solve the issue that you're trying to solve, also? Or else I am probably
still not really understanding why it is important to make a pluggable
factory pattern for DataContexts.

2013/9/12 Hillyard, Robin C <>

> 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
>         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) []
> Sent: Wednesday, September 11, 2013 2:59 PM
> To:
> 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,
> Kasper
> > 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.

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message