Очевидно то, что “данные не удалось сохранить”.

Лучше расскажите как вы объясните пользователю, что у вас Product в БД привязаны к несуществующим Category, а Category содержат несуществующие Product?

Э-эм, а как она утечёт пользователю, если ваш код обязан проверять результат операции вставки данных в БД? Вы же наверняка про UPSERT + транзакции знаете :)

В статье ведь описана ситуация проверки связки данных двух таблиц через третью? Если данные (как у автора) уже есть в БД, то FOREIGN KEY будут автоматически обновлять/удалять зависимости и все описанные проверки в принципе не требуются.

Ещё раз спрашиваю — о какой SQL ошибке идёт речь?

Возможно Я не понял, какую именно проблемы вы пытаетесь решить, но весь этот код не требуется если использовать FOREIGN KEY Constraints при проектировании структуры БД.

Такой взгляд на вещи рационален только если вы желаете взростить социум посредственностей. Рекомендую ознакомиться с фильмом “Whiplash” (2014 года).

“There are no two words in the English language more harmful than «good job».” ©

В моем понимании — файл нельзя “вырезать”. Операция “Cut” у меня стойко ассоциируется с буфером обмена в памяти системы/приложения. Следуя вышеописанной логике, файл действительно можно только переместить операцией “Move”. Возможно именно по этой причине в MacOS сделали “Copy + Move” вместо “Сut + Paste”.

Отдельно хочется обратить внимание, что операция “Copy” помещает в буфер обмента путь до файла. Это позволяет удобно использовать данную операцию при работе с терминалом. Т.е. получается именно “Copy + Paste”.

Сколько эмоций на ровном месте… фе-е.

В Mac OS + Finder этот функционал просто работает иначе:
“To move files in Finder first press Command+C to copy the selected files, then press Command+Option+V to move the copied files to the current folder.”

Объяснение причины этого “иначе”:
”And the Finder menu item changes to 'Move Item Here.' Makes a lot more sense from a UI perspective than Cut and Paste. And it's not likely to happen by accident. Nice little touch.”

Path Finder — “а с объектами / файлами” — да.

Есть подозрение, что это аналог метода extract!(*keys) из Rails.

Почему бы для вызова активити из сервиса не расширить реализацию медиаторов следующим образом:

public class ContextMediator
{
// -- construction

public ContextMediator(Context context) {
mContext = context;
}

// -- properties

protected Context getContext() {
return mContext;
}

// -- functions

protected void startActivity(Class<?> cls)
{
Intent intent = new Intent(mContext, cls);
mContext.startActivity(intent);
}

protected void startActivity(Class<?> cls, Bundle extras)
{
Intent intent = new Intent(mContext, cls);
intent.replaceExtras(extras);

mContext.startActivity(intent);
}

// -- variables

private final Context mContext;

}

public class ActivityMediator extends ContextMediator
{
// -- construction

public ActivityMediator(Activity activity) {
super(activity);
}

// -- properties

protected Activity getActivity() {
return (Activity) getContext();
}

// -- functions

protected void startActivityForResult(Class<?> cls, int requestCode)
{
Intent intent = new Intent(getActivity(), cls);
getActivity().startActivityForResult(intent, requestCode);
}

}


Дальше, соответственно:

public abstract class MyActivity extends Activity {

private ActivityMediator mActivityMediator = new ActivityMediator(this);

public ActivityMediator getActivityMediator(){
return mActivityMediator;
}

}

public abstract class MyService extends Service {

private ContextMediator mContextMediator = new ContextMediator(this);

public ContextMediator getActivityMediator() {
return mContextMediator;
}

}


Можно взглянуть на полную верию ActivityMediator?