Re: ORM EntityStore

[Jiri Jetmar <ju...@gmail.com>]

Hi guys,

there is an interesting project open sourced by Goldman Sachs:

https://github.com/goldmansachs/reladomo

It is a basically a Java ORM with some pretty unique features and the Query
DSL is in some ways similar to what we are using in Apache Polygene :

Person.createPerson("Taro", "Tanaka", "JPN");
Person person = Person.findPersonNamed("Taro", "Tanaka");

Evtl. this can be used as ORM in Apache Polygene ? Looks promising, so lets
see..

Cheers,
Jiri



2017-05-06 10:25 GMT+02:00 Niclas Hedhman <ni...@hedhman.org>:

> Gang,
>
> I have gotten overly angry with Hibernate on $dayjob, and decided to take a
> look at what a ORM-ish implementation in Polygene would look like. And it
> was easier than I expected, so...
>
> Pretty simple,
>
> 0. One "types table" that keep tracks of all types. Content of this is
> probably fully cached.
>
> 1. One type table for each MixinType (except HasIdentity)
>
> 2. One "base entity" table with the Identity, lastmodifed and so on stuff.
>
> 3. Use a different (internal) identity for the "value", which makes it easy
> to fully support non-destructive updates.
>
> 4. Property->SQL on basic types, and Serialization kick in on
> ValueComposites.
>
> 5. Association->SQL is simply a VARCHAR
>
> 6. Named/ManyAssociation->SQL needs an intermediate table per assoc (naming
> is trouble some)
>
> 7. get() becomes a SELECT with one join per mixin type
>
> 8. new/update is bunch of INSERT (if non-destructive is used) SQL
> statement, one for each mixin type plus an UPDATE for "base entity".
>
> 9.  Named/ManyAssociations will also be an INSERT with many values.
>
> 10. JOOQ is awfully helpful in making this, and I am trying to modularize
> it so that people can customize it if needed, at Composite Methods level,
> either by Concerns or overriding Mixin methods.
>
> 11. IF destructive mode is wanted, I suggest that DELETE statements are
> issued to remove old stuff, which makes both modes semantically identical,
> and not a big deal if something is accidentally not removed.
>
> And that is pretty much it. Fairly straight forward, and a far cry from the
> complexity of Hibernate, guessing what it does and why.
>
> NOTE, this is only for "Java Model drives SQL model", but in an
> enterprise-friendly way. I hope that this can be a big "adoption driver".
>
> WDYAT?
>
>
> Cheers
> --
> Niclas Hedhman, Software Developer
> http://polygene.apache.org - New Energy for Java
>

Re: ORM EntityStore

[Niclas Hedhman <ni...@hedhman.org>]

I assume that you are referring to (from sample project)


public static Person findPersonNamed(String firstName, String lastName)
{
    Operation findByFirstNameAndLastName =
        PersonFinder.firstName().eq(firstName)
                    .and(PersonFinder.lastName().eq(lastName));
    return PersonFinder.findOne(findByFirstNameAndLastName);
}

which on paper is somewhat similar.

However, there seems to be rather large hurdles;

  1. They start with an app model in XML
  2. They generate source code from that XML in build time, and quite a bit
of it [1].
  3. The PersonFinder has "Polygene naming", and it is a class that is
regenerated on every build.
  4. Person is a one-time generated class, extending a every time generated
AbstractPerson that follows "getter/setter naming".
  5. Static methods... why?
  6. It seems that transactions are wrapped in a single method, and that
doesn't fit the UnitOfWork workflow [2]
  7. A lot of the generated stuff is about providing a query interface.

The codebase is non-trivial, I give them that. And it might be a lot better
than JPA, I mean it is hard not to be worse.

Now, using it out of the box is probably impossible, and I don't think it
is possible to make this generic enough to be able to leverage Polygene
models, so the alternative would be to fork it and massage it into what we
would need. More effort than _I_ care to go for...


HTH
Niclas


[1]
https://goldmansachs.github.io/reladomo-kata/main-kata-presentation/ReladomoKata.xhtml#(11)

https://goldmansachs.github.io/reladomo-kata/main-kata-presentation/ReladomoKata.xhtml#(12)

[2]
https://goldmansachs.github.io/reladomo-kata/main-kata-presentation/ReladomoKata.xhtml#(65)

On Sat, Jul 22, 2017 at 4:31 PM, Jiri Jetmar <ju...@gmail.com>
wrote:

> Hi guys,
>
> there is an interesting project open sourced by Goldman Sachs:
>
> https://github.com/goldmansachs/reladomo
>
> It is a basically a Java ORM with some pretty unique features and the Query
> DSL is in some ways similar to what we are using in Apache Polygene :
>
> Person.createPerson("Taro", "Tanaka", "JPN");
> Person person = Person.findPersonNamed("Taro", "Tanaka");
>
> Evtl. this can be used as ORM in Apache Polygene ? Looks promising, so lets
> see..
>
> Cheers,
> Jiri
>
>
>
> 2017-05-06 10:25 GMT+02:00 Niclas Hedhman <ni...@hedhman.org>:
>
> > Gang,
> >
> > I have gotten overly angry with Hibernate on $dayjob, and decided to
> take a
> > look at what a ORM-ish implementation in Polygene would look like. And it
> > was easier than I expected, so...
> >
> > Pretty simple,
> >
> > 0. One "types table" that keep tracks of all types. Content of this is
> > probably fully cached.
> >
> > 1. One type table for each MixinType (except HasIdentity)
> >
> > 2. One "base entity" table with the Identity, lastmodifed and so on
> stuff.
> >
> > 3. Use a different (internal) identity for the "value", which makes it
> easy
> > to fully support non-destructive updates.
> >
> > 4. Property->SQL on basic types, and Serialization kick in on
> > ValueComposites.
> >
> > 5. Association->SQL is simply a VARCHAR
> >
> > 6. Named/ManyAssociation->SQL needs an intermediate table per assoc
> (naming
> > is trouble some)
> >
> > 7. get() becomes a SELECT with one join per mixin type
> >
> > 8. new/update is bunch of INSERT (if non-destructive is used) SQL
> > statement, one for each mixin type plus an UPDATE for "base entity".
> >
> > 9.  Named/ManyAssociations will also be an INSERT with many values.
> >
> > 10. JOOQ is awfully helpful in making this, and I am trying to modularize
> > it so that people can customize it if needed, at Composite Methods level,
> > either by Concerns or overriding Mixin methods.
> >
> > 11. IF destructive mode is wanted, I suggest that DELETE statements are
> > issued to remove old stuff, which makes both modes semantically
> identical,
> > and not a big deal if something is accidentally not removed.
> >
> > And that is pretty much it. Fairly straight forward, and a far cry from
> the
> > complexity of Hibernate, guessing what it does and why.
> >
> > NOTE, this is only for "Java Model drives SQL model", but in an
> > enterprise-friendly way. I hope that this can be a big "adoption driver".
> >
> > WDYAT?
> >
> >
> > Cheers
> > --
> > Niclas Hedhman, Software Developer
> > http://polygene.apache.org - New Energy for Java
> >
>



-- 
Niclas Hedhman, Software Developer
http://polygene.apache.org - New Energy for Java