Hi, I agree that clear architectural picture and dataflow would help to understand how to extend and how to deal with its bugs and inefficiencies (doable=>worth investing time/not-doable).
You might want to check specific HandlerStrategy from org.apache.openjpa.meta.strats, i.e. HandlerFieldStrategy.insert() which sets the values for prepared statement and then Row implementation that actually generates prepared statement's SQL: org.apache.openjpa.jdbc.sql.RowImpl::getSQL(DBDictionary) and actually filling it with data: org.apache.openjpa.jdbc.sql.RowImpl::flush(..) This is called through through flush of suitable UpdateManager (AbstractUpdateManager usually). Not seeing the whole picture the architecture does seem quite convoluted just by looking at the stack depth - I have considered adding some fast-path capability for inserts for specific DB (COPY interface of Postgres) but not sure if it's really doable without changing openjpa kernel. Cheers Chris PS. Also changing generated sql for bit more complicated models is not trivial (look for issues related to PARALLEL queries in JIRA) - another place some kind of data flow or functional diagram would be helpful. -- View this message in context: http://openjpa.208410.n2.nabble.com/Custom-data-store-implementation-guidelines-tp7583851p7584074.html Sent from the OpenJPA Users mailing list archive at Nabble.com.
