Я написал свой ответ, и я вижу, что вы сейчас отредактировали сообщение, все еще собираясь опубликовать то, что я написал.
Не уверен, что именно ты хочешь делать именно. Но вот пример того, что я думаю, что вы хотите достичь. Предполагая, что все значения в вашем массиве очищены ... Этот запрос будет работать. Как уже говорилось ранее, вам нужно создать массив со всеми значениями, которые вы хотите найти. Отрегулируйте в соответствии с вашими потребностями.
$ArrayA = array("round", "circle", "something");
$ArrayB = array("red" , "green");
$sql = "SELECT * FROM inventory WHERE Shape IN ('".implode("','",$ArrayA)."') OR Color IN ('".implode("','",$ArrayB)."')";
Пример размещения базы данных;
id Shape Color
1 round red
2 round blue
3 square red
4 square green
5 circle blue
6 circle red
7 circle green
8 something blue
9 something green
Я испытал ту же проблему, и в то время как у меня нет решения, я могу сказать Вам, как я работаю вокруг проблемы.
Из-за того, как, форматируя работы, я сознательно избегаю строк кода, которые чрезмерно длинны. В целом, когда я сохраняю строки короткими, это принимает лучшие решения относительно того, как форматировать код. Это может даже работать с SQL-операторами, например:
public static final String SELECT_SOMETHING = "SELECT"
+ "OBJECTID, THIS, THAT, THEOTHER, THING"
+ " FROM DBNAME.DBSCHEMA.TABLE_T"
+ " WHERE ID = ?";
Эти форматы оператора обоснованно, потому что, где возможные объекты были разделены независимо и конкатенировали вместе. Когда я не делаю этого, я получаю непредсказуемые результаты:
public static final String SELECT_SOMETHING = "SELECT OBJECTID, SOMETHING FROM DBNAME.DBSCHEMA.TABLE_T WHERE ID = ?";
Для комментариев я размещаю их всех в одну строку, если это возможно, и позволяю ее переходу на новую строку, когда она делает форматирование.
Кроме того, возможно изменить стиль с помощью средства форматирования кода, чтобы заставить вещи работать лучше на стиль кодирования. Можно хотеть, чтобы все в команде использовали тот же формат, только избежали конфликтов. Поскольку легче сравнить изменения с другими разработчиками или предыдущие версии с помощью инструмента управления исходным кодом, даже если это делает части кода менее читаемыми, использование средства форматирования все еще было к моему преимуществу.
Однако, я понимаю Ваше разочарование, когда средство форматирования принимает плохие решения!
Нет. (Насколько я знаю, и я имел ту же проблему и много раз выглядел твердым и длинным...),
При ощущении себя сомнительным об ответе на мой собственный вопрос, но существует обходное решение, которое я в настоящее время делаю (примечание: у Меня есть эти правила очистки как сохранять-действие):
Сохраните (с Ctrl/Cmd-S, не знайте, имеет ли значение, как Вы сохраняете), код, и позвольте Eclipse испортить Ваше форматирование. Затем просто нажмите Ctrl/Cmd-Z, чтобы отменить, и сразу повторно сохранить. Формат возвращается назад к его исходному формату и, кажется, сохраняется, как предназначено.
(только для комментариев Javadoc)
Если у меня есть блок текста, который отформатировал просто способ, которым мне нравится, я включаю их <пред> </пред> теги.
если Вы не хотите, чтобы поле стало окончательным (i.i: потому что Вы хотите изменить его при отладке), Вы просто присваиваете его себе на конструкторе. Это получило бы предупреждение затмения, но Ваше поле останется неокончательным.
Для операторов SQL в коде вы можете поместить однострочный символ комментария в конце каждой строки. Тогда форматтер не сможет его переформатировать. Это уродливо, чем не делать этого, но красивее, чем форматирование Eclipse.
StringBuffer sql = new StringBuffer() //
.append("SELECT whatever \n") //
.append("FROM some_table");