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 <a...@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 <a...@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
