Hi Hany, I would go for option 1, using a separate EntityManager. Or at least a separate Connection, without using an EntityManager at all. I don't think a full ORM is needed to write a couple of logs to the database.
I also suggest you take a look at Monolog [1], which is a pretty good logger with a sufficient level of abstraction. You could create a (so called) handler that uses a (separate!) dbal-connection to write logs to the database. Now you can simply configure the logger and pass it to Doctrine and whatever service you need to log with. Those services can now log without knowing where that log will eventually end up. Plus you can easily switch backend for when you find the database is no longer sufficient. You could even have a handler that pushes the logs to a ZeroMQ socket where another server pull them in and stores them (for example). A couple of notes about other options: 3: Doctrine doesn't support nested transactions (because not all db vendors support them). 4: An EntityManager has 1 UnitOfWork only. 5: An EntityManager has 1 Connection only. 6: You can achieve this with Monolog (or something similar). [1]: https://github.com/Seldaek/monolog -- Jasper N. Brouwer (@jaspernbrouwer) On 23 July 2014 at 15:23:02, Hany el-Kerdany ([email protected]) wrote: > Hi all, > > I'm working on a php CLI crawler/parser that uses Doctrine ORM. I want to > log/save data about all php errors and/or exceptions that occur during > execution of the script to their own tables in the same database for later > inspection. > > However, some non-fatal PHP errors might occur during the execution of some > database/doctrine related code, which might cause either: > - The error-logging queries to be executed within the boundaries of an open > transaction (In case of explicit transaction demarcation). > - The error-logging queries will be aggregated and executed within the > current unit of work, along with other queries (In case of implicit > transaction demarcation). > > This might introduce problems (or at least complexities), since maintenance > queries (logging errors) are executed within the boundaries of other > business level transactions. > > Here are the paths that I'm investigating. Which do you recommend? > > 1. Using two separate Entity Managers, one for the regular application > code, and the other for logging. > This seems like the obvious solution, but I'm concerned about the memory > footprint, and whether there's a more efficient solution. > > 2. A signle Entity manager, while having application code executed within > the Unit of work (implicit transaction demarcation), and the logging code > executed as DQL or SQL queries. > I think this would actually work fine, and there would be no overlap > between the queries/transactions, but once I begin to use explicit > transaction demarcation, problems might happen again. > > 3. Letting logging code have their own nested transactions within other > open transactions. > However, a failure in the logging/internal transactions will cause the main > transactions to fail. There's ever one open transaction per connection (as > per doctrine's docs). > > 4. A single Entity Manager with two separate units of work. > I guess there's nothing like "Two units of work at the same time for a > single Entity Manager". > > 5. A single Entity Manager with two connections. > Guess there's nothing like that either. > > 6. Caching and flushing log entries to points in code that I'm sure there's > no other transaction running. > This might work but will introduce code-level complexities. > > I think the options that might work are either 1, or 6. Though I would love > to hear about a more efficient solution. > Any suggestions? > > Thanks > Hany -- You received this message because you are subscribed to the Google Groups "doctrine-user" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/doctrine-user. For more options, visit https://groups.google.com/d/optout.
