polygene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jiri Jetmar <juergen.jet...@gmail.com>
Subject Re: ORM EntityStore
Date Sat, 22 Jul 2017 08:31:42 GMT
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 <niclas@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
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message