Create an account

Very important

  • To access the important data of the forums, you must be active in each forum and especially in the leaks and database leaks section, send data and after sending the data and activity, data and important content will be opened and visible for you.
  • You will only see chat messages from people who are at or below your level.
  • More than 500,000 database leaks and millions of account leaks are waiting for you, so access and view with more activity.
  • Many important data are inactive and inaccessible for you, so open them with activity. (This will be done automatically)

0Day Forums Coding FrameWork Flask Using the same database abstraction in Flask and non-Flask program

Thread Rating:
  • 405 Vote(s) - 3.45 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Options
Using the same database abstraction in Flask and non-Flask program

Offline gunboat917


Valued member
***
Valued member
Posts: 1
Threads: 1
Joined: May 2023
Reputation: 0
Level: 1 [Level]
Total Points: 0
Rank 0 / 1
99% to upload Level
Rank
Activity 0 / 1
99% to upload your Rank
Activity
Experience 1
99% to upload Experience
Experience

Points: 50
#1
08-02-2023, 04:26 PM
Basically, I am trying to share as much database layer code as possible between a Flask application (for a REST API) and a *non-Flask* API.

Is it a good idea to use the same [Flask-SQLAlchemy][1] layer in both the pure Python API (intended to be imported in non-web Python applications) and in the REST API Flask daemon?

I guess another way to phrase, though I am not sure on the terminology, "how do I best share database model between Flask app and a separate Python import library?"

<hr/>
Or from another angle, is there any point in using [Flask-SQLAlchemy][2] in a Flask REST API, if you also want to share the SQL abstraction with an import library. Is it better then to use plain [SQLAlchemy][3]?

<hr/>

Use case: we have a large database with many tables, and want to build both a REST API (for customer access) and a Python import library (for performant internal tools) for accessing the database, but of course share as much code between them as possible.


Related:

-

[To see links please register here]

-

[To see links please register here]

- [SQLAlchemy with Flask -- hybrid models?][4]


[1]:

[To see links please register here]

[2]:

[To see links please register here]

[3]:

[To see links please register here]

[4]:

[To see links please register here]

Reply

Offline gnarling141629


Member
*
Member
Posts: 0
Threads: 0
Joined: Aug 2017
Reputation: 0
Level: inf [Level]
Total Points: inf
Rank nan / 1
100% to upload Level
Rank
Activity inf / 1
99% to upload your Rank
Activity
Experience nan
100% to upload Experience
Experience

Points: 50
#2
08-02-2023, 04:49 PM
Using `Flask-SQLAlchemy` models out of a web context is a matter of creating a Flask application and call

app.test_request_context().push()

The point here is what you will do with your "non web" library.
If it's not a problem to have the whole Flask library installed when you need to use the library then there's no problem at all using it in that way.

If you plan to make performance improvements in the library data accessing code, like using different sessions, concurrency and such, then you're modifying your initial code so it's a totally different scenario. In this case a pure-SQLAlchemy approach might be better but it really depends on the differences between the two patterns.


Normally with models comes methods and using 2 different ORM patterns (`Flask-SQLAlchemy` wrapper models and pure `SQLAlchemy`) means duplicating code.

Reply

« Next Oldest
Next Newest »


Forum Jump:


Users browsing this thread:
1 Guest(s)

©0Day  2016 - 2023 | All Rights Reserved.  Made with    for the community. Connected through