Я использую HSQLDB для создания небольшой программы (с JavaFX gui), и в настоящее время я пытаюсь заставить часть "резервирования" работать (пользователь может добавлять новые или искать существующие в течение ограниченного периода времени), Для этого я уже добавил несколько дат заранее (я использую скрипт database.sql), например:
INSERT INTO reservations(begin, end) VALUES ('2013-08-01', '2013-08-31')
Я уже написал несколько методов (создание, обновление, удаление, поиск, findAll), и теперь я как бы застрял на части "создать".
Я хочу вставить новые резервные копии в БД с помощью
pstmt = con.prepareStatement("INSERT INTO reservations(begin, end) VALUES (?,?)");
но у меня возникают проблемы с созданием новых дат, которые я могу вставить.
pstmt.setDate(1, (java.sql.Date) beg);
Не работает (я использую объекты java.util.Date для сохранения экспортированных дат из БД), он просто отменяет мои тесты (jUnit).
Calendar cal1 = Calendar.getInstance();
cal1.set(2014, 0, 1);
Date beginn = cal1.getTime();
только создает даты в форме: Wed Jan 01 12:23:15 CET 2014
Но (и я не знаю, как именно даты сохраняются в HSQLDB) Я хочу, чтобы дата была "ГГГГ-ММ-ДД".
Итак, какой лучший способ преобразования дат календаря в нужный мне формат (и кастовать их? К сожалению, отличное от String to Date не работает). И: Является ли мой подход к использованию java.util.Date датами в порядке, если я собираюсь использовать JavaFX, чтобы пользователь мог выбрать дату начала и окончания?
Вместо (java.sql.Date) beg
вызывающего ClassCastException
вы должны написать:
new java.sql.Date(beg.getTime()); // provided beg is of type java.util.Date as you wrote
Если вы используете строки в предложении VALUES, вы можете рассмотреть синтаксис JDBC-escape для дат. И ваше выражение "создает только даты в виде: Wed Jan 01 12:23:15 CET 2014" вообще не имеет значения, потому что вы видите только выход метода toString()
из java.util.Date
. Это не относится к внутреннему состоянию или хранилищу в db. Ваше желание "Я хочу, чтобы дата была" ГГГГ-ММ-ДД "." скорее подходит для уровня представления вашего приложения, а не для внутреннего формата хранения db, который у вас нет контроля, кроме выбора соответствующего типа столбца db (здесь: ANSI-SQL-DATE).
В слое представления вы можете использовать такие классы, как SimpleDateFormat
с шаблоном "yyyy-MM-dd" для желаемого результата.
EDIT (из-за вопросов в комментариях):
Хорошо, вам действительно не нужно беспокоиться о toString()
-representation файла java.util.Date
-timestamp. Его внутреннее состояние является лишь длинным, представляющим истекшие миллисы с 1970-01-01, не считая секунд прыжка. Просто игнорируйте стандартный вывод java.util.Date, который скорее отображает контекст системной зоны, а не внутреннее состояние. Использование a.before(b)
вполне нормально и не имеет никакого отношения к странному выводу toString()
-method java.util.Date
.
Кроме того: у вас нет реального контроля над тем, как инструмент базы данных отображает значения столбца даты. В этом секрет используемого вами инструмента. Внутреннее состояние внутри db может быть совсем другим, поэтому каждый db является своего рода черным ящиком.
Но когда вы читаете значения даты из db и представляете данные пользователю, тогда и именно тогда вам нужно беспокоиться о представлении java.util.Date
-objects. Для этого я рекомендовал использовать SimpleDateFormat
- см. Выше. Но эта адаптация (преобразование в читаемый формат человеческой даты) не находится в db-инструменте, а не на уровне JDBC, но только на уровне пользователя -representation, обычно в пользовательском интерфейсе.
java.sql.Date
для БД (в вашемPreparedStatement
), но не с приведением типа!