Comments (11)
As a fan of Clean Architecture , I think this feature is essential. What's better is have another to_entity
method to convert to
pydantic model again.
from odmantic.
Maybe a naive question (I know almost nothing about odmantic internals) but would it be possible to make odmantic work directly with pydantic.BaseModel
, and not have Model
at all? Model
seems to be a kind of wrapper, and without a wrapper it would be more likely that odmantic plays nicely with other libraries based on pydantic.
The only instance-level data I see in Model
is the id
field, so it might work if:
- class-level information such as annotations can be stored externally (e.g. in some kind of singleton)
- you make it mandatory for the pydantic.BaseModel instance to already have the 'id' field
from odmantic.
Maybe a naive question (I know almost nothing about odmantic internals) but would it be possible to make odmantic work directly with
pydantic.BaseModel
, and not haveModel
at all?Model
seems to be a kind of wrapper, and without a wrapper it would be more likely that odmantic plays nicely with other libraries based on pydantic.
No worries @mnieber 😃 ; actually using the odmantic.Model class is necessary. The class itself is not the most important part but the metaclass is. The metaclass allows ODMantic to properly build the model object: provide the Proxy objects enabling filtering through python comparison operators, validating fields definition, providing substitution types for native BSON types to be handled.
While the Domain Object Model is used mainly in the Service Layer as input parameters and return values, the Persistence Object Model focuses on how to store and retrieve objects. Often they are different: most of the times the persistent objects have more attributes than the domain objects. But in basic CRUD, return values are often persistence model instances which are the same or very similar to the domain model instances.
Totally agree @erny , I faced as well the situation where it's needed to convert the odmantic instance to a dict and to parse it again into another pydantic model.
I use attrs = pydantic x.dict(exclude_unset=True) a lot and odmantics Model(**attrs) to create object
I didn't try it yet but it's probably possible to use the pydantic.BaseModel.from_orm
as it would probably reduce the verbosity of the conversion and make it more handy for the developpers. If you had the occasion to try it, I would be really happy to bring this in the documentation or to complete the missing elements to make it work.
As we previously discussed and from the POC you showed @erny , creating ODMantic models from Pydantic models should be possible, in order to be able to pring all the desired functionalities: customize key_name
, primary_key
and also being able to specify the ODMantic Config object.
This should give the Pydantic.BaseModel to ODMantic.Model translation ability.
On top of this, since most of the time the domain objects are simply having fewer fields than the persistence layer objects (ODMantic models), I think that having a method to create pydantic submodels from an ODMantic model would be really helpful when architectures are smaller. I think this could be handled while working on "views" that would provide access to projected mongo documents (i.e. we only fetch a subset of the fields from documents stored in the database).
[setattr(model, attr, value) for attr, value in attrs.items()] for partial updates. While this is not very optimal, it fulfills its job.
The partial updates will be made more simple soon by #39 which will add a new Model.update
method allowing object partial modification from either a pydantic object or a dictionary.
from odmantic.
Unfortunately, this behavior is not currently not supported. A way around however would be to define the pydantic model from the odmantic one. As explained in the usage with pydantic section of the docs.
But maybe having this behavior implemented as well could help.
Actually, I'm pretty sure this could be implemented in the meantime as model inheritance and it wouldn't be a huge effort once the initial inheritance would be implemented.
Being able to inherit from pydantic classes might raise some issues about the field definition (primary key, mongo name) though.
from odmantic.
@art049
I was able to tweak odmantic.model.ModelMetaclass.new a bit as experiment. Here goes en example:
from pydantic import BaseModel, Field
import odmantic
class Publisher(BaseModel):
name: str
founded: int = Field(ge=1440)
location: Optional[str] = None
class BookPublisher(Publisher):
address: str
employees: int = Field(ge=1)
class PublisherDB(odmantic.Model):
__base__ = Publisher
class BookPublisherDB(odmantic.Model):
__base__ = BookPublisher
and here changes to odmantic.model.ModelMetaclass.new:
...
def get_annotations(type_: type) -> dict:
"""Get type annotations of class hierarchy"""
d = {}
if issubclass(type_, pydantic.BaseModel) and type_ != pydantic.BaseModel:
for base in type_.__bases__:
d.update(get_annotations(base))
d.update(type_.__annotations__)
return d
class ModelMetaclass(BaseModelMetaclass):
@no_type_check
def __new__( # noqa C901
...
):
base = namespace.get('__base__')
if base:
namespace['__annotations__'] = get_annotations(base)
superclass
if namespace.get("__module__") != "odmantic.model" and namespace.get(
...
cls = super().__new__(mcs, name, bases, namespace, **kwargs)
if base:
cls.__fields__.update(base.__fields__) # use original fields
cls.__pydantic_model__ = base
return cls
I did some simple tests but there might be a million of cases that don't work
from odmantic.
Thanks @erny for the fix. Do you know if the annotations are still available in the odmantic models with this ?
from odmantic.
@art049 It's not a fix, but a hack (or tweak). Annotations should still be available. But I saw that the tests fail. I didn't do a complete checkout and run the tests locally. I replaced fields with the original pydantic ones, but it seems that your unit test don't like it. I'll try to work on this at another moment soon. Regards.
from odmantic.
@art049 It's not a fix, but a hack (or tweak). Annotations should still be available. But I saw that the tests fail. I didn't do a complete checkout and run the tests locally. I replaced fields with the original pydantic ones, but it seems that your unit test don't like it. I'll try to work on this at another moment soon. Regards.
Yes, the odmantic Field object are not actually inheriting from the pydantic ones. In the beginning I though it would help separating the concerns. But now i think it would actually be helpful to inherit from those directly.
from odmantic.
I have to say in favour of the current implementation after using ODMantic that the Domain Object Model and the Persistence Object Model are different and that this forces us to separate cleanly both layers.
While the Domain Object Model is used mainly in the Service Layer as input parameters and return values, the Persistence Object Model focuses on how to store and retrieve objects. Often they are different: most of the times the persistent objects have more attributes than the domain objects. But in basic CRUD, return values are often persistence model instances which are the same or very similar to the domain model instances.
The service layer must translate domain objects to persistent objects and viceversa. I use attrs = pydantic x.dict(exclude_unset=True)
a lot and odmantics Model(**attrs)
to create objects and [setattr(model, attr, value) for attr, value in attrs.items()]
for partial updates. While this is not very optimal, it fulfills its job.
I also put odmantic models (models.py) into another file as domain objects (schemas.py
) and the service layer (services.py
) imports both (and does the translations), while the presentation layer, the FastAPI REST views, just imports schemas.py
.
from odmantic.
I think I understand the attraction in having both the pydantic model and the omdantic model, because it gives you more options as an odmantic developer (more things you can hook into). But maybe compare this to the example of an ORM that maps dictionaries to a database. If such an ORM works directly with a Python dict
then it will be more attractive to end-users than an ORM that requires you to use "special dicts". In any case, I just wanted to offer this as a suggestion, I have no idea if it's actually feasible.
from odmantic.
Hello everyone 👋. Thanks for tjr great work 🙏.
Is there any improvement on this issue? I didn't try the code and read the entire conversation. It's 3 years old, so I wanted to ask. 🤓
from odmantic.
Related Issues (20)
- Pydantic URLs have stopped working
- Support other document store
- Using deprecated `pydantic.datetime_parse:parse_datetime` in Pydantic HOT 1
- Can't start dev container: multi-python is deprecated
- Optional EmbeddedModel not working HOT 3
- Just started following tutorial in https://art049.github.io/odmantic/ and an error HOT 3
- Any specific reason to not support model inheritance?
- `Optional[str]` triggers `int_parsing` instead of string parsing when used for `odmantic.Model` HOT 4
- Multiple sorting criteria HOT 1
- Mypy issues for odmantic 1.0.0 HOT 2
- Trying to use db_engine.configure_database([User]) HOT 1
- Support Inheritance
- regex is removed in pydantic 2.x this causes the Field class to throw an exception if its used. HOT 1
- Support for Optional types as X | None HOT 1
- Embedded models have to be defined before any normal models that reference them HOT 4
- Question: how to mock/write propper unittests HOT 2
- when a model has many optional field, it will raise unwanted validation type error HOT 4
- Odmantic Does Not Add Pydantic Computed Fields to MongoDB HOT 1
- Aggregation support via the find method HOT 1
- Datetime not updating and not updating frequently
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from odmantic.