What I mean is that you could easily think of other similar frameworks to Spring, or just other scenarios in general, where it would also be useful to externalize table defs. For instance in DataCleaner we have a ridiculous XML format for it which is waaaay verbose. We could basically throw out a few pages of XML in favor or a more concise (although interpreted, so less type-safe) String element in our XML files.
2014-03-05 19:19 GMT+01:00 Henry Saputra <[email protected]>: > Sorry for the late reply. > > I don't think we need to generalize the table def parser for now > because the format of the table definition pretty much fixed. > > But like any framework code, anything that could be injected to > override default behavior is always nice. That is why we added Spring > support at the first place =) > > > - Henry > > On Mon, Feb 24, 2014 at 12:19 PM, Kasper Sørensen > <[email protected]> wrote: > > Hi all, > > > > For the Spring module I needed a way for the user to provide a > > SimpleTableDef object via an externalizable string. So I ended up > building > > a small parser that would take simple table definitions of this form: > > > > person ( > >> id INTEGER, > >> name VARCHAR, > >> birthdate DATE > >> ); > >> company ( > >> id BIGINT, > >> name VARCHAR, > >> logo BINARY > >> ); > > > > > > The parser is right now put directly in the DataContextFactoryBean, but > can > > easily be refactored into a separate parser class... > > > > Do you guys agree that would be a better way forward to make this a > general > > SimpleTableDef parser? I'm thinking that such a parser could have a > general > > purpose and would also benefit in terms of maintenance to be put in the > > core module. > > > > Background: SimpleTableDefs are often used in schemaless stores like the > > MongoDB, CouchDB or HBase stores. Here it serves as a guide from the user > > to model the store. > > > > Best regards, > > Kasper >
