Thanks Jasper :) It seems I got my thinking trapped in the ORM box :). Probably because modeling the log records as entities made it very easy to create the database tables.
You're right, using a simple connection, or DBAL for saving logs would do perfectly fine. I'll also take a good look at Monolog. Thanks as well for the feedback on the other options. Thanks Hany On Wed, Jul 23, 2014 at 5:37 PM, 'Jasper N. Brouwer' via doctrine-user < [email protected]> wrote: > 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 a topic in the > Google Groups "doctrine-user" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/doctrine-user/Td38lnR5c4o/unsubscribe. > To unsubscribe from this group and all its topics, 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. > -- 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.
