polygene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Niclas Hedhman (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (POLYGENE-103) ORM system
Date Sat, 13 May 2017 10:59:04 GMT

    [ https://issues.apache.org/jira/browse/POLYGENE-103?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16009266#comment-16009266

Niclas Hedhman commented on POLYGENE-103:

Work has started on this, locally on my machine. So far, the following is attempted;

For each Mixin Type (i.e. types() in EntityDescriptor) there is one SQL table. Each Property
and Association has its own column.
For each Mixin Type that has one or more of ManyAssocation and/or NamedAssociation, there
is a SQL table with the same name + suffix of _MAPPING. It contains the associationName, the
"position" and the entity reference. "position" either the index number for ManyAssociation
and the name key in NamedAssociation.

Then there is a single "entities" SQL table, that contains the metadata of the entity and
an internal foreign key linking the values in the other tables.

JOOQ is used to handle SQL Dialects and such, but the implementation intends to manage the
SQL DDL. JOOQ's mapping feature is not going to be used, simply using Record.

> ORM system
> ----------
>                 Key: POLYGENE-103
>                 URL: https://issues.apache.org/jira/browse/POLYGENE-103
>             Project: Polygene
>          Issue Type: New Feature
>            Reporter: Niclas Hedhman
> Over the years we have several times tried to figure out how to incorporate ORM technology
to Polygene, and kept failing. Hibernate was tried in 2007, and iBatis was attempted in 2008,
and although the latter showed some reasonable promise, it didn't manage to reach all the
> We have since done a lot to let extensions into the runtime model, and we have more features
around Associations in Property and NamedAssociations which I don't think existed in those
> I think it is time to re-open this effort, as it is the constant push-back whenever I
introduce Polygene to new people. It is an easy "ok, you don't have that, therefor I have
no interest in listening to you." and any other argument is ignored.
> I think it is more important to be able to use existing tables, than to support arbitrary
Polygene Entity structures to always have a reasonable SQL structure. I.e. for the companies
where SQL schema rules as data model supreme. Then from there we could investigate further
what full Mixin support would entail.
> Before starting the implementation, I think we should gather usecase and lay out in documentation
how various common schemas can be handled into Polygene entities and values.
> NOTE: This is ONLY about EntityStore and not about generic query.

This message was sent by Atlassian JIRA

View raw message