Re: groovy 4 ginq

[Michael Gentry <bl...@gmail.com>]

"I know EOF of the olden times had an LDAP adapter..."

Wow, that brings back unpleasant memories...  Speaking of EOF (and I don't
want to hijack this thread, so feel free to reply in a new one), how long
is Cayenne going to support EOModels? It isn't a lot of baggage that is
carried around, but still baggage.


On Thu, Dec 30, 2021 at 4:12 AM Andrus Adamchik <aa...@gmail.com> wrote:

> Not so much of a connector issue, but more of a conceptual limitation.
> Relational backend is implied across the stack, from mapping (FKs, joins)
> to query translation. I know EOF of the olden times had an LDAP adapter,
> and there are JPA engines for NoSQL DBs, but all appear to be really leaky
> abstractions.
>
> If we are to dig in this direction, we will need to start with a model of
> "universal mapping".
>
> Andrus
>
>
> > On Dec 30, 2021, at 4:54 AM, Aristedes Maniatis <ar...@ish.com.au.INVALID>
> wrote:
> >
> > Not that I have a need for it, but how pluggable is the JDBC connector
> part of Cayenne? That is, could the backend be easily exchanged for json or
> some other data source, even if only in a read-only way? Could also be an
> interesting way to demonstrate Modeler to new users...
> >
> >
> > Ari
> >
> >
> > On 30/12/21 1:24am, Andrus Adamchik wrote:
> >> An idea of in-memory query evaluation fits Cayenne to a degree. Though
> it is limited to what we already do with in-memory expression-based
> filtering and sorting. A more fancy data transformation (even a simple
> "toUpperCase" from your example) runs against the basic ORM philosophy
> ("toUpperCase" would be a property that does not directly correspond to a
> value in DB).
> >>
> >> I solved it for myself by splitting use cases in two groups:
> >>
> >> 1. "Data as object graph" where Cayenne is appropriate (most cases)
> >> 2. "Data as data" with extra "plasticity" of changing any piece of data
> on the fly
> >>
> >> For #2 sometimes I'd use Cayenne (e.g. column queries, SQLSelect), but
> most often I'd go with DFLib. The main data object in it is a DataFrame
> (essentially a dynamic in-memory table). DataFrame is not tied to a
> specific object structure, and can be dynamically transformed (columns
> added, removed, changed, rows filtered, joins, unions, etc.). DFLib can do
> what GINQ can and more, but it intentionally sacrifices a familiar OO
> representation to support arbitrary intermediate data states and
> frictionless mapping-free persistence.
> >>
> >> DataFrame df = Csv.load("my.csv")
> >>    .selectColumns("id", "price")
> >>    .selectRows($decimal("price").gt(100.));
> >>
> >> Jdbc.connector(dataSource)
> >>    .tableSaver("db_table")
> >>    .save(df);
> >>
> >> Andrus
> >>
> >>
> >>> On Dec 28, 2021, at 11:50 PM, Aristedes Maniatis
> <ar...@ish.com.au.INVALID> wrote:
> >>>
> >>> I came across this really interesting new feature in groovy 4 today...
> >>>
> >>>            class Person {
> >>>                String name
> >>>                int age
> >>>
> >>>                Person(String name, int age) {
> >>>                    this.name = name
> >>>                    this.age = age
> >>>                }
> >>>            }
> >>>
> >>>            def persons1 = [new Person('Daniel', 35), new
> Person('Linda', 21), new Person('Peter', 30)]
> >>>            def persons2 = [new Person('Jack', 35), new Person('Rose',
> 21), new Person('Smith', 30)]
> >>>
> >>>
> >>>        def output = GQ {
> >>>                from p1 in persons1
> >>>                innerjoin p2 in persons2 on p1.age == p2.age
> >>>                select p1.name.toUpperCase(), p2.name.toUpperCase()
> >>>           }
> >>>
> >>>            assert [['DANIEL', 'JACK'], ['LINDA', 'ROSE'], ['PETER',
> 'SMITH']] == output.toList()
> >>>
> >>>
> >>> So GQ invokes this sql-like query language for Java/groovy objects.
> >>>
> >>>
> >>> Not suggesting it is useful for Cayenne, but interesting nevertheless.
> >>>
> >>>
> >>> Ari
> >>>
> >>>
> >>>
> >>>
> >>> docs:
> https://github.com/apache/groovy/blob/master/subprojects/groovy-ginq/src/spec/doc/ginq-userguide.adoc
> >>>
> >>> examples:
> https://github.com/apache/groovy/blob/master/subprojects/groovy-ginq/src/spec/test/org/apache/groovy/ginq/GinqTest.groovy
> >>>
> >>> src:
> https://github.com/apache/groovy/tree/master/subprojects/groovy-ginq/src/main/groovy/org/apache/groovy/ginq
>
>

"Import EOModel" support

[Andrus Adamchik <aa...@gmail.com>]

> On Jan 1, 2022, at 3:31 PM, Michael Gentry <bl...@gmail.com> wrote:
> 
> "I know EOF of the olden times had an LDAP adapter..."
> 
> Wow, that brings back unpleasant memories...  Speaking of EOF (and I don't
> want to hijack this thread, so feel free to reply in a new one), how long
> is Cayenne going to support EOModels? It isn't a lot of baggage that is
> carried around, but still baggage.

This functionality is not often used, but, believe it or not, there are still substantial systems built on EOF out there. So this button in the Modeler encourages and helps them to migrate to Cayenne. 

Having said that, the current importer is somewhat limited. For instance it does not support multiple models. We at ObjectStyle are developing closed-source CLI tool for the full EOF migration. I am hoping we can open source it at some point. But even if we can't, we can still transfer the current importer to its own simple Bootique CLI. 

So I would say the current Modeler should keep the "Import EOModel" button around, but whatever new Modeler we develop doesn't have to, as the CLI tool will replace it.

Andrus