2014-12-31 2 views
3

Я хочу спросить, есть ли способ решить следующую проблему элегантным способом.Java REST Частичное обновление булевых полей

У меня есть приложение Java Rest, использующее JPA и Jersey. Я хочу иметь возможность частично обновлять свои модели.

Я делаю это одним способом (обновлением), который будет проверять предоставленные поля (! = Null) и только обновлять их. Он отлично работает для всех полей, кроме полей типа boolean.

Я бы очень признателен, если вы можете дать некоторые идеи. Я думал о булеанском типе, но это не кажется очень изящным.

Часть ресурса:

... 

@PUT 
@Path("{id:[0-9][0-9]*}") 
@Consumes(MediaType.APPLICATION_JSON) 
public Response update((@PathParam("id") long id, Event event) { 
    Event _event = dao.find(id); 

    if (event.getTitle()!=null) _event.setTitle(event.getTitle()); 

    // in case variable finished is not provided we should not change anything 
    // if (event.getFinished()!=null) _event.setFinished(event.getFinished()); 

    dao.update(id, _event); 
} 

... 

Модель часть:

@Entity 
@XmlRootElement 
public class Event implements Serializable { 

    private String title; 
    private boolean finished = false; 

    public Event(){}  

    // getters, setters 

    ... 
} 

Javascript часть:

// Those ones work 
Event.post({id:12, title:"Meet with Joe", finished:true} // update all fields 
Event.post({id:12, title:"Meet with Barack", finished:false} // update all fields 
Event.post({id:12, finished:false} // partial update of boolean fields 

// How to achieve this one without affecting other boolean fields? 
Event.post({id:12, title:"Meet with Joe"} 
// We haven't provided "finished" value. We don't want to change it. 
// But system will update unprovided boolean field value with default. 
+0

Я думаю, что ваша модель не отражает ваш прецедент (ы). У вас есть несколько типов событий, но вы хотите сохранить их в одном общем событии? Можете ли вы предсказать, сколько вариантов событий у вас будет? Можете ли вы привести несколько примеров этих изменений? – zbig

+0

Существует только один класс Event. Кроме того, есть еще 10 таких файлов, как id, startDate, endDate. когда я хочу использовать поле, которое не должно сохраняться, я просто добавляю @Transient. – Emin

ответ

0

Я думаю, что нашел решение. Вместо использования аргумента Event in Post лучше использовать JsonObject:

... 

@PUT 
@Path("{id:[0-9][0-9]*}") 
@Consumes(MediaType.APPLICATION_JSON) 
public Response update((@PathParam("id") long id, JSONObject json) { 
    Event _event = dao.find(id); 

    _event.setTitle(json.optString("title")); 
    _event.setFinished(json.optBoolean("finished", _event.getFinished())); // if boolean value is not provided, we don't change it 

    dao.update(id, _event); 
} 

... 
0

семантически, если вы хотите использовать класс событий, чтобы иметь возможность выразить понятие «частичное событие с некоторыми заполненными полями, а некоторые нет», а затем иметь каждое поле с типом, который может быть нулевым, имеет смысл, и ИМО будет «изящным» решением.

Однако, если это означает, что ваше мероприятие теперь имеет возможность иметь нули на том, что должно быть непустым полем, просто потому, что вы хотите также использовать его в этом вызове обновления - я думаю, это та часть вам это не нравится. (т. е. вы по существу используете один и тот же класс событий как модельный объект, который непосредственно представляет запись базы данных, и это частичное представление части события, заполненного только полями)

Другим подходом может быть получение простая карта из клиента (т. е. вместо «события события» в качестве последнего параметра для обновления(), выполните «java.util.Map event») и просто скопируйте значения, которые он содержит. Если вам нужно сделать это много, вы можете использовать отражение, чтобы упростить процесс для дублирования для нескольких типов объектов.

P.S. У меня нет большого опыта работы с Джерси, поэтому я не уверен, что он будет корректно работать с java.util.Map (который является интерфейсом) в качестве типа param или если ему нужен конкретный класс или, возможно, какая-то другая аннотация (s). Но я уверен, что эту концепцию можно заставить работать, если вам нравится этот подход.

+0

Было бы лучше увидеть реальный пример того, как должно работать «событие java.util.Map». благодаря – Emin

Смежные вопросы