I want to know whats the standard way of structuring DB related operations? Because a structure is not defined in the documentation.
E.g. Have a repoclass and have functions written for getUsername likewise?
That's exactly like that.
Your model only contains the entities skeleton. Everything related to querying data for these entities has to be in a Repository.
From the Cookbook:
In order to isolate, test and reuse these queries, it's a good idea to create a custom repository class for your entity and add methods with your query logic there.
Related
We are in situation to create the separate API in Python FastApi for one functionality. Other functionality in Laravel. The application which exists already. It created set of tables and using them. Now, we are required to create Pydantic schemas for new API. That schema has a relationship with existing tables. We don't want to create separate schemas for existing tables.
We are forced to create schemas for existing tables as well in the new API. We don't want to create the separate schemas and models for existing tables.
Kindly suggest
Thanks in advance
If you don't care about automatic documentation you don't need to use pydantic at all - you can just return dict and use swagger. If you do, I have no good news.
As far as I know it's not easily achievable. Even if you have tables definitions implemented in sqlalchemy there is not easy way of creating schema from them (there is a tool but it's still experimental).
There are ORM's that can do that (like tortoise) but you still need to implement schema somewhere. Dynamic creation of python class based on database schema would be very hard, very long, very bugable and would break static checkers so I am pretty sure they never exist.
I am currently looking into the repository patterns and read that repository patterns can be implement in 2 way:-
One repository per entity (non-generic) : This type of implementation
involves the use of one repository class for each entity. For example,
if you have two entities Order and Customer, each entity will have its
own repository.
and
Generic repository : A generic repository is the one that can be used
for all the entities, in other words it can be either used for Order
or Customer or any other entity.
Then I read about the Unit of Work concept and how it can relieve us from database inconsistencies that can be cause by the first way.
My confusion is regarding the second way.
Why would I be needing to use 'Unit of work' when I have created a generic repository?
Since there is no way for any inconsistency to occur.
One way to minimize redundant code is to use a generic repository, and
one way to ensure that all repositories use the same database context
(and thus coordinate all updates) is to use a unit of work class.
But since I am going to have a single generic repository then what is the need?
Usualy You don't have "single" generic repository.
In complex applications, sometimes you have to use many instances in a controller
(for example
var productsRepo = new Repository<Products>();
var userRepo = new Repository<Users>();
This are two different instances of generic repository, and they can cause inconsistent in db (or even Exceptions, if both have different dbContext and you try to modify entities in both repositories).
Thats why You have to manage dbContext properly, and Unit Of Work is one of many ways to accomplish it.
I have an existing sqlite db schema (about 30 table) which I have to import into my Android project.
I'd like to use greenDao in my code but I don't know how it's possible if I have already sqlite db created.
Is it possible to work with greenDao even if I haven't my pojo/entity class generated by greenDao Generator? Could I generate them manually?
I think I need also DaoMaster and DaoSession!??!
Thank you very much.
I've never done it, but theoretically, yes you can.
From greenDao FAQ page:
Can I use existing entity classes? Can I skip entity generation?
Yes. In your generator project, call setSkipGeneration(true) on entities you do not want to generate. Like this, you have the most possible control over your entities at the cost of manual maintenance. However, this is considered advanced usage and should be reserved for special cases only: the recommended way is to generate entities and use “keep sections” to inject custom code into them. If you choose to skip entity generation, you must either provide a constructor with all property fields in the order they were added in the generator project. Or alternatively, call setConstructors(false) on entities to make greenDAO use setters instead of the constructor to create entities.
I understand that you have to implement the generator project normally but skype de generation of the entities. This should generate the DaoMaster and DaoSession only.
Would it be possible to create a similar entity based on another one? For example, what if I'd like to have user specific tables that are based on one entity. Without any ORM I would just create the same table with a different prefix and do the queries on the table with the specific prefix.
Not sure how to tackle the problem with Symfony 2.5 and Doctrine and I just can't find a concrete example anywhere around, but seems like the solution might be around the Doctrine Event Manager and the Load ClassMetadata event. I just can't make sense out of the documentation.
Without exactly knowing how your schema looks or what you're trying to achieve, it's hard to give a precise answer. But let's try:
If you have two entities which share a common set of properties, but differ in others, you basically do the typical OOP inheritance thing, you create an abstract parent class with the common stuff, and two children with their specific properties.
In Doctrine, there are different inheritance strageties. Read about them at http://doctrine-orm.readthedocs.org/en/latest/reference/inheritance-mapping.html
Each of them has their pros and cons. Basically, you can select if you want everything to be in one or in two tables. Set up a test case and check what works better for you.
Note: The class properties in an abstract superclass (no matter which strategy) must always be private.
I'm attempting to setup Entity Framework using Code First on an existing database. The database isnt in great shape (poor naming convention and some constraints are needed). The application I'm building is an MVC app. I have a "Model", "Repository", and "Web" (mvc) tiers.
To setup EF and map my model objects (POCO objects), is it required that I match my objects to database tables? Can I, instead, use my own stored procedures for CRUD operations? Would it help if I use WCF data services?
I'm planning on using fluent configurations to map my objects, but having some issues due to the database schema. I'm know considering redesigning the database just to get EF to map correctly. Any suggestions would be greatly appreciated!!
Looks awfully similar to this question:
Does Entity Framework Code First support stored procedures?
The answers there may be helpful to you, as well as the discussion surrounding how Code First and Stored Procedures don't make a whole lot of sense.
Wow, Julie Lerman answered!
Yes, it's possible, but not particularly easy. In particular, you must call context.Database.SqlQuery<T>() where T is the entity type you want to return, and your SQL must match up to that entity type. Otherwise, you will have to massage a result set into a type.
In general, you will have to do most of this manually, although you could probably figure out a T4 template to generate it for you, or maybe use some other tool like CodeSmith.