On Fri, Mar 5, 2021, at 11:00 AM, Jonathan Brandmeyer wrote:
>
>
> On Fri, Mar 5, 2021 at 8:29 AM Mike Bayer wrote:
>> __
>> Can I ask what documentation led you to believe that engine.connect() was
>> somehow being removed ?
>
> The guidance at [1] makes it clear that the connection is
On Fri, Mar 5, 2021 at 8:34 AM Mike Bayer wrote:
> yeah in fact that engine.begin() here is using a brand new SQLite
> connection each time as the default pool for SQlite files is NullPool, as
> it is a very fast connecting database and it is the safest option for
> concurrency. So in your
On Fri, Mar 5, 2021 at 8:29 AM Mike Bayer wrote:
> Can I ask what documentation led you to believe that engine.connect() was
> somehow being removed ?
>
The guidance at [1] makes it clear that the connection is available as a
transaction context manager. However, the guidance at [2] suggests
yeah in fact that engine.begin() here is using a brand new SQLite connection
each time as the default pool for SQlite files is NullPool, as it is a very
fast connecting database and it is the safest option for concurrency. So in
your first example, you have a brand new file connection and all
OK this is not hard to understand, in one case you are connecting fresh from
the connection pool each time and in the other you are reusing the same
Connection which will be much more performant. The second example that states
"runtime 3.1 seconds" is perfectly acceptable code for SQLAlhcemy
On Thu, Mar 4, 2021 at 5:00 PM Mike Bayer wrote:
> hey there-
>
> engine.begin() does not do anything to the SQLite connection at all as
> there is no begin() method in the Python DBAPI. this is why in your
> logging you will see a line that says "BEGIN (implicit)". nothing
> happened. the
hey there-
engine.begin() does not do anything to the SQLite connection at all as there is
no begin() method in the Python DBAPI. this is why in your logging you will
see a line that says "BEGIN (implicit)". nothing happened. the pysqlite driver
controls the scope of the actual BEGIN on the
We are currently on v1.3, but we've noticed the big announcements about the
2.0 API and are reviewing our practices with future migration in mind.
One of our applications is INSERT-heavy and also uses SQLite. Standard
performance guidance in this situation SQLite is to use the write-ahead
