Prüfungen für constraint-Verletzung vor dem fortbestehen einer Entität

Was ist der beste Mechanismus für die Verhinderung von constraint-Verletzung überprüft vor der Erstellung | änderung einer Entität?

Angenommen, wenn der 'Benutzer' entity 'loginid', wie die unique-Einschränkung, würde es klug sein, zu überprüfen, ob eine Eingabe bereits mit dieser loginid Namen vor der Erstellung oder änderung.

ODER

Ließ Sie die Datenbank werfen eine ConstraintViolationException und behandeln Sie diese Nachricht entsprechend in der UI-Schicht. Wo sollten diese Kontrollen durchgesetzt werden, die im jboss seam framework.

Hinweis: Derzeit keine solche Kontrollen erzwungen werden, die Naht-gen-code.

Wir verwenden derzeit Seam 2.2, Richfaces mit Hibernate.

InformationsquelleAutor Joe | 2010-01-30

  1. 6

    Sogar wenn die Bedingung in den code vor dem speichern des Benutzer-Objekt gibt es immer eine chance, dass jemand erstellt ein Duplikat loginid zwischen der Zeit, die Sie überprüfen und wenn Sie weiterhin dem neuen Benutzer.

    Aber es wird einfacher sein, um die Anzeige einer entsprechenden Fehlermeldung in der Benutzeroberfläche wenn Sie eine explizite überprüfen. Wenn Sie mehrere Constraints auf den Tisch, fangen die ConstraintViolationException nicht zulassen, dass Sie leicht bestimmen, welche constraint verletzt worden ist.

    Also ich würde beides tun. Angenommen, Sie sind sich von der Naht ist EntityHome:

    1. In der persist () - Methode eine Abfrage ausführen, um sicherzustellen, dass die loginid ist einzigartig. Wenn Sie nicht hinzufügen eine Fehlermeldung an die entsprechende Steuerung und null zurückgeben.
    2. Wickeln Sie den Aufruf super.persist() und fangen Sie die ConstraintViolationException, zeigt einen generischen doppelte Fehlermeldung

    BEARBEITEN

    Als Shervin erwähnt Erstellung eines JSF-Validator ist eine tolle Idee (Ersatz) #1 oben, aber man sollte doch erwarten das Schlimmste und fangen ConstraintViolationException.

    Wie verhindern Sie, dass diese Fragen, wenn ein standalone-client stellt eine direkte JPA anrufen. Wie können wir den code wiederverwendbar über diese Szenarien?
    Hat die standalone-client immer eine direkte JPA anrufen, oder können Sie erzwingen, dass es über einen DAO von einer Sorte?
    Wir sind mit Seam-Komponenten (EntityHome, EntityQuery Schnittstellen), die derzeit dienen als Bindeglied zwischen der Benutzeroberfläche und der JPA-Persistenz-Schicht. Es ist mir nicht klar, wenn ich könnte Durchsetzung des standalone-clients zu verwenden, die Naht abstraction layer für die Persistenz statt der PPV-Schicht direkt zu. Wenn Naht-Schicht muss vorhanden sein, dann Naht Bibliotheken werden muss, versendet als Teil der client-toolkit. Nicht sicher, was ist der beste Ansatz hier
    Dass kann dazu führen, ziemlich viel extra-Abfragen, die die performance beeinflussen schlecht.

    InformationsquelleAutor mtpettyp

  2. 6

    Ich bin nicht einverstanden mit der Handhabung ConstraintException. Ich habe geschrieben einen validator, der prüft Duplikate vor dem speichern, und es funktioniert Super.

    Hier ist ein Beispiel bei der Kontrolle von doppelten E-Mails.

    @Name("emailValidator")
@Validator
@BypassInterceptors
@Transactional
public class UniqueEmailValidator implements javax.faces.validator.Validator, Serializable {

private static final long serialVersionUID = 6086372792387091314L;

@SuppressWarnings("unchecked")
public void validate(FacesContext facesContext, UIComponent component, Object value) throws ValidatorException {
    EntityManager entityManager = (EntityManager) Component.getInstance("entityManager");
    String newEmail = (String) value;
    String oldEmail = String.valueOf(component.getAttributes().get("oldEmail"));
    if (oldEmail != null && !oldEmail.equalsIgnoreCase(newEmail)) {
        List<User> users = entityManager.createQuery(
                "SELECT DISTINCT u FROM " + User.class.getName() + " p where lower(p.fromEmail) = :email").setParameter("email",
                newEmail.toLowerCase()).getResultList();
        if (!users.isEmpty()) {
            Map<String, String> messages = Messages.instance();
            throw new ValidatorException(new FacesMessage(FacesMessage.SEVERITY_ERROR, messages.get("admin.emailexists"), messages
                    .get("admin.emailexists")));
        }
    }
}
}

    Und im Formular (xhtml) schreiben Sie:

    <s:decorate template="/layout/definition.xhtml">
        <ui:define name="label">#{messages['processdata.email']}</ui:define>
        <h:inputText id="fromEmail" size="30" required="true" value="#  {userAdmin.existingUser.fromEmail}">
            <f:validator validatorId="emailValidator"/>
            <f:attribute name="oldEmail" value="#{userAdmin.existingUser.fromEmail}" />
            <s:validate />
        </h:inputText>
    </s:decorate>

    Diese Weise wird es immer überprüfen Sie das Feld vor dem speichern. Sie können auch setzen Sie ein ein:support-tag zu überprüfen, wenn sich der Fokus verändert.

    Wenn Sie Ihre Datenbank mit eindeutigen, dann wird es eine Ausnahme auslösen, und Ihre Allgemeine exception-handler zu beheben.
    Es gibt noch eine chance, dass die DB aktualisiert werden kann, mit einer doppelten E-Mails zwischen den "Prozess-Validierungen" und "Update Model" JSF-Phasen und eine ConstraintException würde geworfen werden.
    Nicht wahrscheinlich, dass dies passieren wird, wenn Sie mit Optimistic locking, ie @Version

    InformationsquelleAutor Shervin Asgari

  3. 2

    Mein Rat ist, dass, wenn Sie können prüfen, eine Bedingung, dann überprüfen Sie es also in Ihrem Fall UserExists-Methode aufrufen. Auslösen von Ausnahmen ist teuer und soll für außergewöhnliche Fälle in der Regel Bezug auf die Dinge außerhalb Ihrer Kontrolle, wie z.B. "disc access", etc

    Würden Sie in der Regel diese Prüfung in Ihrer business-Logik ein, bevor Sie die Person in die Datenbank aufgenommen.

    Ja, meine einzige Sorge mit diesem Ansatz ist, dass einige Fragen haben, die entlassen werden, für fast jede Erstellung oder änderung des Datensatzes. Ich bin gerade auf der Suche nach dem besten Ansatz, die Nutzer bevorzugen. Dank
    Die Frage ist: was ist teurer, die Prüfung auf JEDEN writeoperation der DB oder Behandlung einer Ausnahme nur, wenn etwas schief geht?

    InformationsquelleAutor David

Schreibe einen Kommentar