Hi Ben,

Many thanks for that.  Sounds like there's quite a few obstacles at the moment.  I feel that whatever mapping solution is eventually used to implement transactions, it should *ideally* be also used to deliver the complex features in the read direction.  Given the one-way nature of CQL, this would probably mean looking for an alternative ORM to that currently used.  You mention this as a possibility, so I hope it's not too abhorrent to suggest undoing (some of) your hard work!

One of the options we're looking at is the use of RIF to define how the complex features map back and forth from simple ones.  There is much discussion about whether RIF is mature enough, but it's certainly one of the options we're looking at.  Obviously, there's still quite a bit of background reading and research we need to do, but the questions you raise all need answering and will help us evaluate the different options.

I'll certainly keep you and the group posted with progress.

Regards,

Andy



On 14/12/2010 02:08, Ben Caradoc-Davies wrote:
Andrew,

there are technical barriers, such as the lack of support for parsing 
complex GML features. WFS-T would require parsing complex features 
before they could be inserted into a database. app-schema is build on 
simple features, and so locking would have to be coordinated with these. 
Furthermore, feature chaining would mean that related features would 
also have to be locked.

The biggest technical problem in my view is that CQL expressions are 
used to implement polymorphism (conditionals) and to construct data in 
the middleware. CQL expressions are in general irreversible. This is a 
huge problem in using the existing mapping as it stands. So perhaps a 
new mapping might be required? (Or a new ORM backend that addresses both 
reversibility and efficiency in one go?)

One conceptual hurdle is object identity and referential integrity. When 
you update a complex feature, are you also updating nested properties, 
or just the top-level feature? What about properties that are shared 
between multiple features (associations)? What about multivalued 
attributes: do you need to garbage collect to preserve foreign key 
constraints?

Sorry, I have more questions than answers. This is an interesting 
problem.  :-)

Kind regards,
Ben.

On 13/12/10 20:02, Andrew Chamberlain wrote:
Hi All,

We were just sizing up the task of enabling transactions with the
app-schema plugin, and were wondering if anyone knew of any major issues
which might prevent / trouble the development of this?  Questions which
immediately come to mind are:

1) Would the current mappings be re-usable, or would a separate set be
needed for the reverse (i.e. write) direction?
2) Would such a reverse mapping be possible with the current mechanisms?

I'm hoping that the original reason that transactions wasn't implemented
was simply a matter of limited time and funds, and not something technical.

Any thoughts/pointers would be much appreciated.

Best regards,

Andy

------------------------------------------------------------------------------
Oracle to DB2 Conversion Guide: Learn learn about native support for PL/SQL,
new data types, scalar functions, improved concurrency, built-in packages,
OCI, SQL*Plus, data movement tools, best practices and more.
http://p.sf.net/sfu/oracle-sfdev2dev
_______________________________________________
Geoserver-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geoserver-users


------------------------------------------------------------------------------
Lotusphere 2011
Register now for Lotusphere 2011 and learn how
to connect the dots, take your collaborative environment
to the next level, and enter the era of Social Business.
http://p.sf.net/sfu/lotusphere-d2d
_______________________________________________
Geoserver-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geoserver-users

Reply via email to