metamodel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hillyard, Robin C" <robin_c_hilly...@uhc.com>
Subject RE: [jira] [Commented] (METAMODEL-27) Non-extensible DataContextFactory
Date Wed, 09 Oct 2013 13:42:41 GMT
Yes. I will work on it.

-----Original Message-----
From: Kasper Sørensen [mailto:i.am.kasper.sorensen@gmail.com] 
Sent: Wednesday, October 09, 2013 3:36 AM
To: dev@metamodel.incubator.apache.org
Subject: Re: [jira] [Commented] (METAMODEL-27) Non-extensible DataContextFactory

Is this something you feel like spending time on doing? If you can propose a draft solution
to begin with that would be great to get it going...


2013/10/8 Hillyard, Robin C <robin_c_hillyard@uhc.com>

> Thanks for your comments. I only just saw your response today.
>
> I think your DataContextFactoryBean idea is a good one, probably a 
> more satisfactory solution than my interface suggestion, at least in 
> terms of generalizing the mechanism for constructing data contexts.
>
> I'm not sure if it would address the other aspect (but it might, 
> depending on the implementation). To wit, the unnecessary loading of 
> classes for data stores of no interest. If the proposed factory bean 
> loaded such classes on request (that is at configuration time) then it 
> would not be necessary for an application even to have available the 
> jar files for stores that it didn't need.
>
> -----Original Message-----
> From: Kasper Sørensen [mailto:i.am.kasper.sorensen@gmail.com]
> Sent: Thursday, September 12, 2013 3:25 PM
> To: dev@metamodel.incubator.apache.org
> Subject: Re: [jira] [Commented] (METAMODEL-27) Non-extensible 
> DataContextFactory
>
> 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 <robin_c_hillyard@uhc.com>
>
> > 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:jira@apache.org]
> > Sent: Wednesday, September 11, 2013 2:59 PM
> > To: dev@metamodel.incubator.apache.org
> > 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=
> > 13
> > 764626#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.
> >
>
> 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.
>
>

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.


Mime
View raw message