Yeah generic parser should be useful. And it should injectable through
the Spring context for extension/ override I suppose.

- Henry

On Wed, Mar 5, 2014 at 12:09 PM, Kasper Sørensen
<[email protected]> wrote:
> 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
>>

Reply via email to