#328 Openjump and Postgis

Bernd Wehle

Windows XP (32bit), openjump rev. 3597, Java 1.7.0_17:
on newer postgis-databases Openjump can not write new features as multipolygon into the database.
in the attachment is a longer text and sampledata.
we are using EPSG31468 for correct coodinates.

1 Attachments


  • Thanks for the feed back,

    I try to answer to some points included in the
    zip file.
    You are right, Potgis driver can help to store
    and to manage large datasets for a single user,
    but it is not ready for a multi-users scenario.

    I have some ideas to improve it, but managing
    identifiers so that the database can be shared
    and updated from several clients is more complex
    than it seems to be.

    There is one think which is quite clear :
    the database must be responsible for giving new
    ids to new features.
    another point which is much less clear is :
    when a new feature is committed, the database gives
    it a new id in the database, but how this id is
    given back to openjump feature ? The only way I
    see for now is to delete new features in the client
    and to update the layer from the database, not very

    Refreshing a layer :
    refresh datastore layer refreshes a layer created with File > Open > Datastore
    refresh database query refreshes a layer created with File > Execute SQL query

    null gid
    one tip I can give you (just a tip, not a final
    solution for the problem you are rising) :
    create your gid attribute as a dynamic attribute with
    beanshell and enter FEATURE.ID as the formula, so that
    the attribute will be filled automagically with the
    unique client fid each time you create a new feature.
    Here is a small video I made to illustrate this tip :


  • Bernd Wehle
    Bernd Wehle

    Hello Michaël

    thanks for your answer. You know, my english is supported by google…
    My report is written in viewing of multiuser-senarios and the postgis-extension for multiuser is a big Milestone and "must have"…
    With the question "gid is null, why?" i wanted to draw attention to the necessary dialogue between client and database, which is required for saving the features.
    I hope i can a little bit help with my ideas.

    But step for step.
    OJ knows the project properties even for postgis-layers, it must be remember to this before the dialog to save the data/features starts.
    The existing dialogues do not bring happiness

    Second and not easy:
    OJ can with "select all modified features" the last actions of the users analyze for the basis to storing the data.

    Informix has a function: SQLCA.SQLERRD[2] for columns with SERIAL-datatype.
    The called program receive a RECORD with the next number in column number two. The result can displayed for the user and/or used in the program:
    "let my_number= SQLCA.SQLERRD[2]".
    At 1995 and above I have this used in i-4gl.

    I'm not a developer, i'm only an old experienced user and i think, this problem of the postgis-driver is only cleared with transactions and dialogues like this
    (very simplified):

    for (all_new_features with gid is null)
    client: "database, i will save this new feature (without gid), what is the next gid?"
    database: "client, your question with nextval(my_sequence_gid) has this result,
    the record is saved …."
    client "database, thanks for your message, my internal feature.gid is updated,
    the user can see this in the objectinfo or the attribut-window."
    end transaction
    next feature
    end for.

    similar oj must deal with existing, only changed elements. And that works okay, except for the dialogue in the first step.

    Is this the way without big stones?

    I have found this in the WEB:
    postgis creates a "sequence" for every shape-dataset. ?

    nextval(my_sequence) is the next id for the feature within a transaction

    with best regards

    • status: open --> closed-accepted
    • assigned_to: michael michaud
  • As you already noticed, I made a big step forward in that direction with WritableDataStoreDataSource.
    I close this ticket which is a bit outdated. Feel free to create new ones if you find bugs in the new plugin.