los objetos de lectura persistieron pero aún no se han borrado con la doctrina

Soy nuevo en symfony2 y doctrine. aquí está el problema como I verlo. no puedo usar:los objetos de lectura persistieron pero aún no se han borrado con la doctrina

$repository = $this->getDoctrine()->getRepository('entity'); 
$my_object = $repository->findOneBy($index);

en un objeto que se persistió, PERO NO ENJUAGADA YET !! Creo que getRepository lee de DB, por lo que no encontrará un objeto que no se haya descargado.

mi pregunta: ¿cómo leer los objetos que se conservan (creo que están en algún lugar de una "sesión de doctrina") para volver a utilizarlos antes de lavar todo el lote?

cada perfil tiene 256 penachos físicos.

cada perfil tiene 1 plumeOptions registro asignado.

En plumeOptions, tengo una cartridgeplume que es un FK para PhysicalPlume.

cada penacho se identifica por ID (autogenerado) y INDEX (generado por el usuario).

regla: Digo perfil 1 tiene physical_plume_index número 3 (= índice) conectado a él.

ahora, quiero copiar un perfil con todos sus datos relacionados a otro perfil.

se ha creado un nuevo perfil. Se crean y copian 256 nuevos plumes desde un perfil anterior.

Quiero enlazar el nuevo perfil para el nuevo índice penacho 3.

cheque aquí: http://pastebin.com/WFa8vkt1

Fuente

2011-10-24 xeon

creo que es posible que desee echar un vistazo a esta función:

$entityManager->getUnitOfWork()->getScheduledEntityInsertions()

Le devuelve una lista de objetos de entidad que aún persisten.

Hmm, realmente no leí bien su pregunta, con lo anterior obtendrá una lista completa (como una matriz) pero no puede consultarla como con getRepository. Intentaré encontrar algo para ti ...

Fuente

2011-10-24 17:03:26

thx por su respuesta. verifique mi [editar] sección ... – xeon

¿Puedo hacer una doble descarga() dentro de mi acción? nunca lo intenté, pero solo una pregunta ... ¿tal vez una tonta?!? limpie las plumas recién creadas, y luego continúo buscando las otras plumeOptions y ahora puedo vincularlas a las plumas recién creadas. ¿Cómo encuentras esa idea ...? (¡con suerte, no es tan estúpido!) – xeon

Por lo que yo sé, puedes llamar a flush() tantas veces como quieras. La práctica recomendada para el ejercicio es hacer esto lo menos posible para preservar el tráfico de conexión. Pero si necesita una identificación de sus entidades añadidas anteriores, entonces es una buena práctica. –

Creo que podrías ver el problema desde el ángulo equivocado. Doctrine es su capa de persistencia y capa de acceso a la base de datos. Es responsabilidad de su modelo de dominio proporcionar acceso a los objetos una vez que están en la memoria. Entonces, ¿el problema se reduce a how do you get a reference to an object without the persistance layer?

¿Dónde crea el objeto que necesita para obtener más tarde? ¿Puede el método/servicio que crea el objeto devolver una referencia al controlador para que pueda propagarlo al otro lugar que lo necesite? ¿Puede enviar un evento que escuche en otro lugar de su aplicación para obtener el objeto?

En mi opinión, Doctrine debe usarse al inicio de la aplicación (lo antes posible), para inicializar el modelo de dominio y al cerrar la aplicación, para persistir cualquier cambio en el modelo de dominio durante la solicitud . Usar un repositorio para retener objetos en el medio de una solicitud es, en mi opinión, probablemente un olor a código y debería ver cómo se puede refactorizar el flujo de la aplicación para eliminar esa necesidad.

Fuente

2011-10-24 18:07:37 PatrikAkerstrand

No estoy seguro de estar de acuerdo en que no es el trabajo de Doctrine para proporcionar acceso. Al menos en Zend, Doctrine se usa como ** Entity Manager **, que para mí suena exactamente como el lugar que debería contener referencias a objetos. Después de que el código ha determinado que quiere persistir y la entidad, la capa de persistencia, Doctrine, debe ser la única que (en general) necesita preocuparse acerca de si las entidades se escriben en DB aún o no. Aunque tal vez en Zend, el EntityManager puede proporcionar otra forma de acceder a entidades que no sean los repositorios de Doctrine, pero si es así, no sé cuál es. –

No creo que haya entendido la pregunta: / – xDaizu

Tu es un problema de lógica de negocios eficaz.

La consulta de la base de datos de una consulta de búsqueda en el objeto que todavía no se ha descargado significa aumentar mucho más el objeto de consulta de la capa de base de datos que ya tiene en su ámbito de función.

También tenga en cuenta que un findOneBy recuperará también otros objetos previamente guardados con las mismas características.

Si necesita encontrar solo entre esos objetos creados nuevos, debe hacer que f.e. en una variable de matriz de sesión, y repetirlos con el foreach.

Si necesita una combinación de elementos ya guardados + algunos elementos nuevos, debe amenazar las 2 partes por separado, una con un foreach, otra con la consulta del repositorio.

Fuente

2012-07-13 15:03:59 giuseppe

los objetos de lectura persistieron pero aún no se han borrado con la doctrina

Respuesta

Cuestiones relacionadas