prevent scoped_session closing the connection when there are active sessions

[petrkalos]

Feature or Bugfix

• Bugfix

Detail

Currently if there are nested scoped_session is calls the inner call will close the connection and wipe all the tracked objects. As a result post commit modifications to the objects will not be commited properly. The following code demostrates the issue...

import datetime

from sqlalchemy import Column, Integer, String
from sqlalchemy.ext.declarative import declarative_base

from dataall.base.db import get_engine

# Create base class for declarative models
Base = declarative_base()

# Define a sample model
class TestUser(Base):
    __tablename__ = 'test_users'
    id = Column(Integer, primary_key=True)
    name = Column(String)
    email = Column(String)
    test_dt = Column(String)

# Create engine and connect to database
# engine = create_engine('postgresql://postgres:docker@localhost:5432/dataall')
engine = get_engine(envname='dkrcompose')

# Create tables
Base.metadata.create_all(engine.engine)

# Create session factory
with engine.scoped_session() as session:
    new_user = TestUser(name='John Doe', email='[email protected]')
    session.add(new_user)
    session.commit()
    with engine.scoped_session() as session2: # end of this block will call session.close() and will wipe the tracked objects (new_user)
        new_user = session2.query(TestUser).filter_by(name='John Doe').first()
    # this change will not be commited because `new_user` is no longer tracked by the session
    new_user.name = 'Jane Doe'
    new_user.test_dt = datetime.datetime.now()

The fix provided here is to introduce an active_session counter and only close the connection when all sessions are done.

Security

Please answer the questions below briefly where applicable, or write N/A. Based on
OWASP 10.

• Does this PR introduce or modify any input fields or queries - this includes
  fetching data from storage outside the application (e.g. a database, an S3 bucket)?
  • Is the input sanitized?
  • What precautions are you taking before deserializing the data you consume?
  • Is injection prevented by parametrizing queries?
  • Have you ensured no eval or similar functions are used?
• Does this PR introduce any functionality or component that requires authorization?
  • How have you ensured it respects the existing AuthN/AuthZ mechanisms?
  • Are you logging failed auth attempts?
• Are you using or adding any cryptographic features?
  • Do you use a standard proven implementations?
  • Are the used keys controlled by the customer? Where are they stored?
• Are you introducing any new policies/roles/users?
  • Have you used the least-privilege principle? How?

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.