openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Patrick Linskey (JIRA)" <j...@apache.org>
Subject [jira] Updated: (OPENJPA-277) Provide a simple means for manual specification of all SQL used by a given domain graph
Date Thu, 05 Jul 2007 17:39:04 GMT

     [ https://issues.apache.org/jira/browse/OPENJPA-277?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Patrick Linskey updated OPENJPA-277:
------------------------------------

    Attachment: OPENJPA-277.patch

Simplify the process of specifying totally-custom SQL for insert, update, delete, and find
operations.

Currently, ManualSQLClassStrategy depends on the annotations directly, rather than on ClassMapping
data or some other indirected configuration data. This is in part due to laziness, and in
part because I wanted to create this patch with an absolute minimum amount of changes to OpenJPA.


Also, the current ordering implementation in AnnotationPersistenceMetaDataParser is very inefficient.
We should fix that before doing anything with this code.

We should consider using things like insertable=false, updatable=false to turn off certain
fields, meaning that the corresponding columns would not be needed in the corresponding operations.

This patch has a class declaration that looks like so:

@Entity
@NamedNativeQuery(name = "ManualSQL.findRecords",
    query = "select * from MS",
    resultSetMapping = "ManualSQL.findRecords.mapping")
@SqlResultSetMapping(name = "ManualSQL.findRecords.mapping", ... })

@Strategy("org.apache.openjpa.persistence.jdbc.ManualSQLClassStrategy")
@ManualSQL(
    insert="insert into MS(ms_id, ms_stringField, ms_aft) values (?, ?, ?)",
    find="select ms_stringField, ms_aft from MS where ms_id = ?",
    update="update MS set ms_stringField = ?, ms_aft = ? where ms_id = ?",
    delete="delete from MS where ms_id = ?"
)
public class ManualSQLInstance { ... }


The patch relies on either the natural field ordering (as defined by FieldMetaData.getListingIndex(),
which is computed either based on the field declaration order in the Java source or in the
orm.xml file if present), or the @ManualSQL#fieldOrder annotation property. Additionally,
this currently only works with SQL, although this could be easily expanded. We might want
to move to a deeper annotation structure to allow for more fine-tuning of things like whether
SQL or stored procs should be used on a statement-by-statement basis.

> Provide a simple means for manual specification of all SQL used by a given domain graph
> ---------------------------------------------------------------------------------------
>
>                 Key: OPENJPA-277
>                 URL: https://issues.apache.org/jira/browse/OPENJPA-277
>             Project: OpenJPA
>          Issue Type: New Feature
>          Components: jdbc
>    Affects Versions: 0.9.0, 0.9.6, 0.9.7
>            Reporter: Patrick Linskey
>         Attachments: OPENJPA-277.patch
>
>
> Generally-speaking, OpenJPA generates the SQL needed to load records from the database.
Currently, the only mainstream exception to this is when using SQL as a query language.
> In legacy environments, database access is often limited to certain SQL statements or
stored procedures. OpenJPA should support such environments for a larger subset of OpenJPA
operations.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message