BT
@PandaThePanda надо было выключить widescreen mode в settings -> appearance, чтобы нижняя панель растянулась
Size: a a a
2020 March 10
P
@PandaThePanda надо было выключить widescreen mode в settings -> appearance, чтобы нижняя панель растянулась
а ну
P
я в этих панельках
P
не разбираюсь))
BT
вот теперь так
AM
#not_flood
AM
Переслано от Grzegorz `gzhegow` Brzęczyszczykiewicz
Позвольте уточнить, я увидел несколько реализаций Persistence кардинально отличающихся друг от друга.
JPA в java предлагает EntityManager с собственной реализацией блокировок и транзакций, entity кладется в метод persist(), в конце вызывается метод flush() и базы синхронизируются
- не понимаю как из одной базы перекачивают в другую, если метод flush() явно должен быть привязан к какой-то одной? под каждый источник EntityManager?
- зачем им сдался метод detach() / clear() - который отвязывает Entity от базы данных, но при этом позволяет по прежнему на него опираться другим связанным сущностям, это разве разумнее, чем сравнивать изменилась ли Entity с момента последнего find() ?
Встретил в интернетах форум, где Net-овцы спорят о том что Repository дескать помер, и нужно классы просто именовать как запросы class FindUserByEmail() и делать метод execute(), затем делать QueryBuilder где в виде обычных методов объявлять все эти классы потом, но что-то мне подсказывает что QueryBuilder будет не просто гигант, а ультрагигант
У PHPшников есть пример https://designpatternsphp.readthedocs.io/en/latest/More/Repository/README.html, где PersistenceInterface идет с InMemoryPersistence примером, где не ясно каким образом чтобы этих хранилищ было несколько, учитывая наличие в интерфейсе метода generateId(), ведь в реляционной базе не генерируют Id, чтобы потом выполнить UPDATE, так или иначе сначала нужен INSERT, а полностью пустую запись далеко не всегда можно инсертить из-за ограничений индексов. И потом - если ID всегда есть, эта штука может попросту не понять, что запись нужно инсертить и выполнить UPDATE по сгенерированному ID автоматически. пример отличный при условии что Persistence это только хранение в памяти. Был кстати какой-то автор, который умудрился разделить значит Persistenc-ы на два типа - State-dependent и Constant, дескать если они в памяти то с ними нужно add/merge, а если они в удаленном источнике - то save()/create()/update(), но помоему это чушь
Кто знаком с вопросом что именно берет на себя обьект Persistence, и каким образом он понимает что обновить, что инсертить, как выбросить исключение по уникальному индексу не доводя до реляционки, и как сливать несколько источников данных, когда айдишники могут дублироваться, а данные при этом разные?
JPA в java предлагает EntityManager с собственной реализацией блокировок и транзакций, entity кладется в метод persist(), в конце вызывается метод flush() и базы синхронизируются
- не понимаю как из одной базы перекачивают в другую, если метод flush() явно должен быть привязан к какой-то одной? под каждый источник EntityManager?
- зачем им сдался метод detach() / clear() - который отвязывает Entity от базы данных, но при этом позволяет по прежнему на него опираться другим связанным сущностям, это разве разумнее, чем сравнивать изменилась ли Entity с момента последнего find() ?
Встретил в интернетах форум, где Net-овцы спорят о том что Repository дескать помер, и нужно классы просто именовать как запросы class FindUserByEmail() и делать метод execute(), затем делать QueryBuilder где в виде обычных методов объявлять все эти классы потом, но что-то мне подсказывает что QueryBuilder будет не просто гигант, а ультрагигант
У PHPшников есть пример https://designpatternsphp.readthedocs.io/en/latest/More/Repository/README.html, где PersistenceInterface идет с InMemoryPersistence примером, где не ясно каким образом чтобы этих хранилищ было несколько, учитывая наличие в интерфейсе метода generateId(), ведь в реляционной базе не генерируют Id, чтобы потом выполнить UPDATE, так или иначе сначала нужен INSERT, а полностью пустую запись далеко не всегда можно инсертить из-за ограничений индексов. И потом - если ID всегда есть, эта штука может попросту не понять, что запись нужно инсертить и выполнить UPDATE по сгенерированному ID автоматически. пример отличный при условии что Persistence это только хранение в памяти. Был кстати какой-то автор, который умудрился разделить значит Persistenc-ы на два типа - State-dependent и Constant, дескать если они в памяти то с ними нужно add/merge, а если они в удаленном источнике - то save()/create()/update(), но помоему это чушь
Кто знаком с вопросом что именно берет на себя обьект Persistence, и каким образом он понимает что обновить, что инсертить, как выбросить исключение по уникальному индексу не доводя до реляционки, и как сливать несколько источников данных, когда айдишники могут дублироваться, а данные при этом разные?
AK
какой-то поток сознания
AK
не буду этого наркомана читать
ЕР
Я два раза перечитал и всё-равно не осилил чего он хочет, далее лень стало)
AK
вот да, аналогично, но я на 1 разе сдался
BT
ну он упоротый, это давно известно
объект Persistence - на этом все
объект Persistence - на этом все
AL
Переслано от Grzegorz `gzhegow` Brzęczyszczykiewicz
Позвольте уточнить, я увидел несколько реализаций Persistence кардинально отличающихся друг от друга.
JPA в java предлагает EntityManager с собственной реализацией блокировок и транзакций, entity кладется в метод persist(), в конце вызывается метод flush() и базы синхронизируются
- не понимаю как из одной базы перекачивают в другую, если метод flush() явно должен быть привязан к какой-то одной? под каждый источник EntityManager?
- зачем им сдался метод detach() / clear() - который отвязывает Entity от базы данных, но при этом позволяет по прежнему на него опираться другим связанным сущностям, это разве разумнее, чем сравнивать изменилась ли Entity с момента последнего find() ?
Встретил в интернетах форум, где Net-овцы спорят о том что Repository дескать помер, и нужно классы просто именовать как запросы class FindUserByEmail() и делать метод execute(), затем делать QueryBuilder где в виде обычных методов объявлять все эти классы потом, но что-то мне подсказывает что QueryBuilder будет не просто гигант, а ультрагигант
У PHPшников есть пример https://designpatternsphp.readthedocs.io/en/latest/More/Repository/README.html, где PersistenceInterface идет с InMemoryPersistence примером, где не ясно каким образом чтобы этих хранилищ было несколько, учитывая наличие в интерфейсе метода generateId(), ведь в реляционной базе не генерируют Id, чтобы потом выполнить UPDATE, так или иначе сначала нужен INSERT, а полностью пустую запись далеко не всегда можно инсертить из-за ограничений индексов. И потом - если ID всегда есть, эта штука может попросту не понять, что запись нужно инсертить и выполнить UPDATE по сгенерированному ID автоматически. пример отличный при условии что Persistence это только хранение в памяти. Был кстати какой-то автор, который умудрился разделить значит Persistenc-ы на два типа - State-dependent и Constant, дескать если они в памяти то с ними нужно add/merge, а если они в удаленном источнике - то save()/create()/update(), но помоему это чушь
Кто знаком с вопросом что именно берет на себя обьект Persistence, и каким образом он понимает что обновить, что инсертить, как выбросить исключение по уникальному индексу не доводя до реляционки, и как сливать несколько источников данных, когда айдишники могут дублироваться, а данные при этом разные?
JPA в java предлагает EntityManager с собственной реализацией блокировок и транзакций, entity кладется в метод persist(), в конце вызывается метод flush() и базы синхронизируются
- не понимаю как из одной базы перекачивают в другую, если метод flush() явно должен быть привязан к какой-то одной? под каждый источник EntityManager?
- зачем им сдался метод detach() / clear() - который отвязывает Entity от базы данных, но при этом позволяет по прежнему на него опираться другим связанным сущностям, это разве разумнее, чем сравнивать изменилась ли Entity с момента последнего find() ?
Встретил в интернетах форум, где Net-овцы спорят о том что Repository дескать помер, и нужно классы просто именовать как запросы class FindUserByEmail() и делать метод execute(), затем делать QueryBuilder где в виде обычных методов объявлять все эти классы потом, но что-то мне подсказывает что QueryBuilder будет не просто гигант, а ультрагигант
У PHPшников есть пример https://designpatternsphp.readthedocs.io/en/latest/More/Repository/README.html, где PersistenceInterface идет с InMemoryPersistence примером, где не ясно каким образом чтобы этих хранилищ было несколько, учитывая наличие в интерфейсе метода generateId(), ведь в реляционной базе не генерируют Id, чтобы потом выполнить UPDATE, так или иначе сначала нужен INSERT, а полностью пустую запись далеко не всегда можно инсертить из-за ограничений индексов. И потом - если ID всегда есть, эта штука может попросту не понять, что запись нужно инсертить и выполнить UPDATE по сгенерированному ID автоматически. пример отличный при условии что Persistence это только хранение в памяти. Был кстати какой-то автор, который умудрился разделить значит Persistenc-ы на два типа - State-dependent и Constant, дескать если они в памяти то с ними нужно add/merge, а если они в удаленном источнике - то save()/create()/update(), но помоему это чушь
Кто знаком с вопросом что именно берет на себя обьект Persistence, и каким образом он понимает что обновить, что инсертить, как выбросить исключение по уникальному индексу не доводя до реляционки, и как сливать несколько источников данных, когда айдишники могут дублироваться, а данные при этом разные?
Ну давай разберем по частям, тобою написанное ))
P
Переслано от Grzegorz `gzhegow` Brzęczyszczykiewicz
Позвольте уточнить, я увидел несколько реализаций Persistence кардинально отличающихся друг от друга.
JPA в java предлагает EntityManager с собственной реализацией блокировок и транзакций, entity кладется в метод persist(), в конце вызывается метод flush() и базы синхронизируются
- не понимаю как из одной базы перекачивают в другую, если метод flush() явно должен быть привязан к какой-то одной? под каждый источник EntityManager?
- зачем им сдался метод detach() / clear() - который отвязывает Entity от базы данных, но при этом позволяет по прежнему на него опираться другим связанным сущностям, это разве разумнее, чем сравнивать изменилась ли Entity с момента последнего find() ?
Встретил в интернетах форум, где Net-овцы спорят о том что Repository дескать помер, и нужно классы просто именовать как запросы class FindUserByEmail() и делать метод execute(), затем делать QueryBuilder где в виде обычных методов объявлять все эти классы потом, но что-то мне подсказывает что QueryBuilder будет не просто гигант, а ультрагигант
У PHPшников есть пример https://designpatternsphp.readthedocs.io/en/latest/More/Repository/README.html, где PersistenceInterface идет с InMemoryPersistence примером, где не ясно каким образом чтобы этих хранилищ было несколько, учитывая наличие в интерфейсе метода generateId(), ведь в реляционной базе не генерируют Id, чтобы потом выполнить UPDATE, так или иначе сначала нужен INSERT, а полностью пустую запись далеко не всегда можно инсертить из-за ограничений индексов. И потом - если ID всегда есть, эта штука может попросту не понять, что запись нужно инсертить и выполнить UPDATE по сгенерированному ID автоматически. пример отличный при условии что Persistence это только хранение в памяти. Был кстати какой-то автор, который умудрился разделить значит Persistenc-ы на два типа - State-dependent и Constant, дескать если они в памяти то с ними нужно add/merge, а если они в удаленном источнике - то save()/create()/update(), но помоему это чушь
Кто знаком с вопросом что именно берет на себя обьект Persistence, и каким образом он понимает что обновить, что инсертить, как выбросить исключение по уникальному индексу не доводя до реляционки, и как сливать несколько источников данных, когда айдишники могут дублироваться, а данные при этом разные?
JPA в java предлагает EntityManager с собственной реализацией блокировок и транзакций, entity кладется в метод persist(), в конце вызывается метод flush() и базы синхронизируются
- не понимаю как из одной базы перекачивают в другую, если метод flush() явно должен быть привязан к какой-то одной? под каждый источник EntityManager?
- зачем им сдался метод detach() / clear() - который отвязывает Entity от базы данных, но при этом позволяет по прежнему на него опираться другим связанным сущностям, это разве разумнее, чем сравнивать изменилась ли Entity с момента последнего find() ?
Встретил в интернетах форум, где Net-овцы спорят о том что Repository дескать помер, и нужно классы просто именовать как запросы class FindUserByEmail() и делать метод execute(), затем делать QueryBuilder где в виде обычных методов объявлять все эти классы потом, но что-то мне подсказывает что QueryBuilder будет не просто гигант, а ультрагигант
У PHPшников есть пример https://designpatternsphp.readthedocs.io/en/latest/More/Repository/README.html, где PersistenceInterface идет с InMemoryPersistence примером, где не ясно каким образом чтобы этих хранилищ было несколько, учитывая наличие в интерфейсе метода generateId(), ведь в реляционной базе не генерируют Id, чтобы потом выполнить UPDATE, так или иначе сначала нужен INSERT, а полностью пустую запись далеко не всегда можно инсертить из-за ограничений индексов. И потом - если ID всегда есть, эта штука может попросту не понять, что запись нужно инсертить и выполнить UPDATE по сгенерированному ID автоматически. пример отличный при условии что Persistence это только хранение в памяти. Был кстати какой-то автор, который умудрился разделить значит Persistenc-ы на два типа - State-dependent и Constant, дескать если они в памяти то с ними нужно add/merge, а если они в удаленном источнике - то save()/create()/update(), но помоему это чушь
Кто знаком с вопросом что именно берет на себя обьект Persistence, и каким образом он понимает что обновить, что инсертить, как выбросить исключение по уникальному индексу не доводя до реляционки, и как сливать несколько источников данных, когда айдишники могут дублироваться, а данные при этом разные?
О
P
Это же знатный поех
P
Он шизил ещё в пхпгикс
P
Я по аватарке узнал
AK
а я по титлу
AK
гримджоу там