Mapped Types (example) broken

[clauspruefer]

Code

import mincepy
import uuid

historian = mincepy.connect('mongodb://127.0.0.1/mince-mapped-types', use_globally=True)

class Car:
    def __init__(self, make='ferrari', colour='red'):
        self.make = make
        self.colour = colour

    def __str__(self):
        return "{} {}".format(self.colour, self.make)


class CarHelper(mincepy.helpers.TypeHelper):
    TYPE = Car
    TYPE_ID = uuid.UUID('21605412-30e5-4f48-9f56-f0fa8014e746')
    make = mincepy.field()
    colour = mincepy.field()

historian.register_type(CarHelper)

Exception

File "/home/cpruefer/Documents/mincepy/mincepy-test.py", line 15, in <module>
    class CarHelper(mincepy.helpers.TypeHelper):
    ...<3 lines>...
        colour = mincepy.field()
TypeError: HelperMeta.__new__() missing 2 required keyword-only arguments: 'obj_type' and 'type_id'

Python Version

cpython 3.13.3

Blame Me

Sorry, did not have much time for debugging deeper myself.

Remark

I had the plan to integrate mincepy into my python-micro-esb project, but it does not really match the requirments. The mincepy interface uses direct class assignment / Mapped Types, the python-micro-esb uses hierachical class instancing / relation mapping from JSON metadata.

In my oppinion the mincepy base conecpt / layout is pretty cool (especially the object transformation and versioning feature). If i had more time (and money) i would love to participate.

[muhrin]

Hi @clauspruefer ! Thanks a lot for your comments and for spotting this!

So what's happened is that I changed the syntax in the latest version, and forgot to update the docs. My hope had been to allow backward compatibility with the way you've done it as well, but apparently my plan wasn't successful.

In any case, you can do it like this:

...
class CarHelper(
    mincepy.helpers.TypeHelper,
    obj_type=Car,
    type_id=uuid.UUID("21605412-30e5-4f48-9f56-f0fa8014e746"),
):
    make = mincepy.field()
    colour = mincepy.field()


historian.register_type(CarHelper)

The reason for this change was that I felt this syntax better reflects the fact that the certain properties (obj_type, type_id, etc belong to the metaclass).

My plan now is to:

1. See if I can still support the previous syntax, and,
2. Update the docs.

python-micro-esb looks cool by the way, and I see the mismatch with mincepy's goals. Indeed, I'm mainly int the python data science/machine learning space so I wanted a tight coupling between python classes and mapped data to keep the learning curve relatively flat for people who are happy working with python. You might want to check out DLite, a library created by colleagues of mine in Norway: https://github.com/SINTEF/dlite , I think this is somewhat closer to what you're doing.

[clauspruefer]

Hi @clauspruefer ! Thanks a lot for your comments and for spotting this!

So what's happened is that I changed the syntax in the latest version, and forgot to update the docs. My hope had been to allow backward compatibility with the way you've done it as well, but apparently my plan wasn't successful.

In any case, you can do it like this:

...
class CarHelper(
mincepy.helpers.TypeHelper,
obj_type=Car,
type_id=uuid.UUID("21605412-30e5-4f48-9f56-f0fa8014e746"),
):
make = mincepy.field()
colour = mincepy.field()

historian.register_type(CarHelper)

The reason for this change was that I felt this syntax better reflects the fact that the certain properties (obj_type, type_id, etc belong to the metaclass).

BETTER!

My plan now is to:

1. See if I can still support the previous syntax, and,

2. Update the docs.

python-micro-esb looks cool by the way, and I see the mismatch with mincepy's goals. Indeed, I'm mainly int the python data science/machine learning space so I wanted a tight coupling between python classes and mapped data to keep the learning curve relatively flat for people who are happy working with python. You might want to check out DLite, a library created by colleagues of mine in Norway: https://github.com/SINTEF/dlite , I think this is somewhat closer to what you're doing.

Of course! The only difference to micro-esb compared to mincepy is the way of initially setting up class instances / feeding them with metadata. This is what the micro-esb does automagically / adds a layer on top for doing this in a declarative way (modeling a) the class-hierarchy model and b) the service input metadata inside JSON config files).

The micro-esb is WebService / Cloud Microservices centric, its primary design is aimed for high-speed ⏩ data aggregation / routing between hierarhichal microservice systems or direct data sources like classical relational SQL or NoSQL systems. This could maybe quite interesting in projects like OpenModel or similar 💡 After micro-esb version 1.2 or 1.3 has been finished the project also will be converted into c++ (Copilot AI does this in minutes 🦾).

I thought over and over again after the mincepy mapping code failed if i can use mincepy as relational mapping to MongoDB inside micro-esb and my first impression was: NO. But now after i implemented the mapping by myself i revise the stament: it is quite well fitted and i will give it a try in the next micro-esb release. The complexity lies in the data processing order, if done manually: easy going. Data has to be applied from tree "end-nodes" first and then attached to the parent in a recursive way: this is working now. Same logic can be applied when integrating mincepy, so should be max. 1 day implementation time. I will inform you when finished!

[clauspruefer]

@muhrin Another documentation remark: mongodb package has been removed from apt on debian and ubuntu, it is only installable from downloadable .deb package described here:

https://www.mongodb.com/docs/manual/administration/install-community/?operating-system=linux&linux-distribution=ubuntu&linux-package=default&search-linux=with-search-linux

The mincepy documentation still refers to apt-get install mongodb command.