Is it good practice to copy all sqlalchemy models (tables) for every API I create?

[Desmond Lim]

Hi there,

I'm just wondering what is the best way to do this. I'm not asking about micro-services, just a general API coding practice.

Currently, I have a number of APIs (separate code base) and each has their own model (e.g. users) and the endpoints create don't need anymore tables (models) except the ones it uses. We have also left out the relationships between the tables.

I haven't used ORMs at this level of separation before (all of my previous projects have all been 1 giant application) so I'm not sure what is the best way to do this. We are starting to develop APIs that would require it to span a few tables.

My query is: 

1. Is it good practice to copy all the models (tables) for each API that we'll be creating? Have a directory of all the models and copy this directory to every API we create.
2. Or is it better to just just the models (tables) that this model will be using? Just copy the models that this API needs.
   
3. Is it a bad idea to leave out the relationships?

Thanks.

Desmond

[Jonathan Vanasco]

Are all of these APIs for the same company/organization (e.g. in-house services), or are you developing something for different companies (you are an agency with clients)?

If everything is for the same company, I typically define and maintain a single model in a dedicated separate package.  The various applications then import and use that single model.  The model has it's own unit-tests to ensure everything works as expected, but some tests are in the projects as well.  Build/Deploy on each application runs the single model's tests too. This ensures no project breaks the model.

[Desmond Lim]

Thanks Jonathan. Exactly what I wanted to know.

Desmond

On Tue, 14 May 2019 at 02:22, Jonathan Vanasco <jona...@findmeon.com> wrote:

Are all of these APIs for the same company/organization (e.g. in-house services), or are you developing something for different companies (you are an agency with clients)?

If everything is for the same company, I typically define and maintain a single model in a dedicated separate package.  The various applications then import and use that single model.  The model has it's own unit-tests to ensure everything works as expected, but some tests are in the projects as well.  Build/Deploy on each application runs the single model's tests too. This ensures no project breaks the model.

--
SQLAlchemy -
The Python SQL Toolkit and Object Relational Mapper
 
http://www.sqlalchemy.org/
 
To post example code, please provide an MCVE: Minimal, Complete, and Verifiable Example. See http://stackoverflow.com/help/mcve for a full description.
---
You received this message because you are subscribed to the Google Groups "sqlalchemy" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sqlalchemy+...@googlegroups.com.
To post to this group, send email to sqlal...@googlegroups.com.
Visit this group at https://groups.google.com/group/sqlalchemy.
To view this discussion on the web visit https://groups.google.com/d/msgid/sqlalchemy/e8bb854b-e2cd-476a-9158-9ef9bf18b477%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Desmond Lim]

As told by Jonathan, I’m trying to create a separate package for the models. Can anyone point me in the right direction to create the models as a module. I can’t seem to think how to do it because of the different ways you can connect to the database and there is the unit test to do. I just need a pointer or some reference to do this.

Thanks.

Desmond

On 14 May 2019, 02:22 +0800, Jonathan Vanasco <jona...@findmeon.com>, wrote:

Are all of these APIs for the same company/organization (e.g. in-house services), or are you developing something for different companies (you are an agency with clients)?

If everything is for the same company, I typically define and maintain a single model in a dedicated separate package.  The various applications then import and use that single model.  The model has it's own unit-tests to ensure everything works as expected, but some tests are in the projects as well.  Build/Deploy on each application runs the single model's tests too. This ensures no project breaks the model.

--

[Jonathan Vanasco]

i have a few projects families with a model like this:


/shared_model/setup.py
/shared_model/shared_model/
/shared_model/shared_model/sqlalchemy_api/..
/shared_model/shared_model/sqlalchemy_model/..
/shared_model/shared_model/utils/...
/shared_model/tests_unit


the sqlalchemy_model directory just has the objects and relationships as derived from declarative_base() and metadata.  the `sqlalchemy_api` has some integrated model operations that are used in multiple projects. 

the various apps that use the library themselves will create an engine and call configure_mappers. the unit tests also create their own engine.  i keep it that way, because the various frameworks I use have their own ways of specifying database connection details.