Interesting project.
I agree with Ari. Independent that the target would not be a analytical
databases, LinkETL is itself a ETL tool that fits perfectly in the data
mediation, following wikipedia definition for ETL[3]:
"As such, ETL is a key process to bring all the data together in a
standard, homogeneous environment".
On the other hand, about:
"(the sequence of operations can be represented as extract/transform/load
at the higher level, although not all algorithms involved match this
simplified description)"
you are still having the magic of a plus in order to include the rest of
stuff, it leaves us: LinkETL+ :)
Two more points:
- I have been specially catched by the section in the description part
that makes emphasis on the "CSV sources out of the box", so what about
something like: LinkSrc, LinkSources, LinkDB
- On the other hand, due we still moving on the relational escenary,
what about: LinkER, LinkRel
Emerson
On Fri, Jun 12, 2015 at 9:04 AM, Andrus Adamchik <and...@objectstyle.org>
wrote:
> > I have a friend who does ETL and it sounds like exactly the sort of
> thing he'd use. Why is ETL not a suitable choice?
>
> ETL as a process is very close to what the product does (the sequence of
> operations can be represented as extract/transform/load at the higher
> level, although not all algorithms involved match this simplified
> description). However everything I read about ETL has data warehouse as the
> target of the load. So the nature of the "transform" and "load" phases is
> aligned with data warehouse design ("star schema") and requirements. It
> usually involves intermediate data stores, etc.
>
> LinkETL on the other hand is not specifically targeting analytical
> databases. It features a more lightweight data pipeline (though you can
> build a more complicated process by combining the jobs) that can be
> embedded in a Java webapp. Also it has a strong synergy with your
> application stack. Especially true if you use Cayenne as your ORM, but we
> can extend it to JPA or Hibernate models. You'd place the Java component of
> LinkETL under the same source control area as your apps, and change it as
> you data model evolves. (The mapping part you keep outside your Java
> project, and change it on both source and target changes...)
>
> > Are you wanting something to tie into the "LinkREST" brand?
>
> Doesn't have to be actually. Though using "Link" prefix makes creating a
> unique name easier.
>
> > * LinkRouter
> > * LinkShip
> > * LinkLoad
>
>
> Thanks! Another suggestion that I got offline last night was LinkMove
> (which also happens to be a pun on LinkRest :) ).
>
> Andrus
>
>
>
> > On Jun 12, 2015, at 3:28 AM, Aristedes Maniatis <a...@maniatis.org>
> wrote:
> >
> > On 12/06/2015 12:48am, Andrus Adamchik wrote:
> >> Now we realized that "ETL" in the name is wrong, as it has data
> warehouse connotations. So looking for another name for this project. All
> the most obvious names (e.g. 'datapump") are already taken by various
> commercial and open source projects. So I figured we may croudsource the
> name selection :) So asking the community for the naming ideas...
> >
> > I have a friend who does ETL and it sounds like exactly the sort of
> thing he'd use. Why is ETL not a suitable choice?
> >
> > Are you wanting something to tie into the "LinkREST" brand?
> >
> > * LinkRouter
> > * LinkShip
> > * LinkLoad
> >
> >
> > Ari
> >
> >
> >
> > --
> > -------------------------->
> > Aristedes Maniatis
> > GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A
> >
>
>
