On 2/11/11 3:53 PM, Pablo Godel wrote:
Yes, I know that Doctrine dependency would not be good, but maybe an
optional Storage could be useful.
The current implementation tries to use sqlite3 extension and if it is
not present, it tries PDO. I guess the order could be reversed in case
PDO is not present.
The default should still be SQLite as there is no need to configure
anything. Having a PDO storage sounds good to me. If you have a look on
github, I'm pretty sure I stumbled upon a MySQL implementation some time
ago.
Fabien
Pablo
On Fri, Feb 11, 2011 at 12:04 AM, Jeremy Mikola <[email protected]
<mailto:[email protected]>> wrote:
Since the profiler is in a component, I'm not sure a Doctrine
dependency would be best (at least initially). PDO sounds
worthwhile, though, since it'd allow us the most flexibility
(SQL-wise). I'm not sure if sqllite is a core extension, but I PDO
certainly should be.
A future improvement might be leveraging Doctrine DBAL for the
connection management (this can be done in the WebProfilerBundle).
On Thu, Feb 10, 2011 at 11:34 PM, Pablo Godel <[email protected]
<mailto:[email protected]>> wrote:
Hello all,
During some tests on one of my applications that makes a good
number of Ajax calls, I kept getting a lot of exceptions from
the profiler when it could not write to sqlite3 due to locking
issues.
In SF, I asked Fabien and he said there is not much we can do
about it with sqlite3.
After looking at the SQLiteProfilerStorage class, wouldn't make
more sense to convert this class to use PDO so it can use any
other db driver, pretty much like the PdoSessionStorage? I would
definitively use MySQL in my case to avoid locking issues. I can
see how this could benefit others as well. I would also write a
MongoDB version for us as we use Mongo a lot so would like to
know if someone wants to include it in core.
I assume that doing PDO is better than relaying on Doctrine to
avoid having a dependency with it but a Doctrine2ProfileStorage
could also be another alternative.
Adding another storage is fairly easy and could be done outside
of the core, but the current implementation takes the path to
the sqlite3 db in the constructor. I think it would make more
sense to take a dsn instead to make it more universal and
extendable?
As a side note, the name of SQLiteProfilerStorage is not
consistent with other class lines like PdoSessionStorage.
If there is consensus for any of the proposed changed above, I
volunteer myself to make the implementation and changes.
Thanks
Pablo
--
If you want to report a vulnerability issue on symfony, please
send it to security at symfony-project.com
<http://symfony-project.com>
You received this message because you are subscribed to the Google
Groups "symfony developers" group.
To post to this group, send email to
[email protected] <mailto:[email protected]>
To unsubscribe from this group, send email to
[email protected]
<mailto:symfony-devs%[email protected]>
For more options, visit this group at
http://groups.google.com/group/symfony-devs?hl=en
--
jeremy mikola
--
If you want to report a vulnerability issue on symfony, please send
it to security at symfony-project.com <http://symfony-project.com>
You received this message because you are subscribed to the Google
Groups "symfony developers" group.
To post to this group, send email to [email protected]
<mailto:[email protected]>
To unsubscribe from this group, send email to
[email protected]
<mailto:symfony-devs%[email protected]>
For more options, visit this group at
http://groups.google.com/group/symfony-devs?hl=en
--
If you want to report a vulnerability issue on symfony, please send it
to security at symfony-project.com
You received this message because you are subscribed to the Google
Groups "symfony developers" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/symfony-devs?hl=en
--
If you want to report a vulnerability issue on symfony, please send it to
security at symfony-project.com
You received this message because you are subscribed to the Google
Groups "symfony developers" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/symfony-devs?hl=en
