Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Protected/Private has attributes should be omitted when report #1366

Open
ypkang opened this issue Oct 11, 2024 · 3 comments
Open

Protected/Private has attributes should be omitted when report #1366

ypkang opened this issue Oct 11, 2024 · 3 comments
Assignees
Labels
jac cloud Issues related to the jac-cloud package

Comments

@ypkang
Copy link
Contributor

ypkang commented Oct 11, 2024

Describe the feature you'd like

Private has variables should be omitted when reported.

Examples

node Doc {
  has text: str = "This is a text".
  has:priv embedding: list[float];
}

d = Doc();
report d;

The reported data of node d should not include the private attribute embeddings.

@ypkang ypkang added the jac cloud Issues related to the jac-cloud package label Oct 11, 2024
@ypkang
Copy link
Contributor Author

ypkang commented Oct 11, 2024

@amadolid I think this one is pretty straightforward. If you also agree this makes sense, you can go ahead and pick this up.

@amadolid
Copy link
Collaborator

I don't think private annotation is the right annotation for this as It's usually for inheritance and encapsulation. In this context, it will describe the embedding is private and only accessible in node Doc while also not declaring a method or process how to manipulate it on the same node.

On other OOP, we usually annotate it to be ignored during de serialization via decorator. Example

@json_ignore("field1", "field2")
node Doc {}
#or

node Doc {
   class MetaData:
      json_ignore = ["field1", "field2"]
}

There's multiple way to override it but I think the proper way is to use decorator or override __serialize__ method

@amadolid
Copy link
Collaborator

amadolid commented Oct 18, 2024

Additional,

Using this approach will also affect how we communicate to other external services (ex: databases, 3rd party service).
We will need to maintain 2 serialization method for report and database serialization.

The most common practice on known frameworks is by having a single serialization per model and convert it to another DTO to have a safer/cleaner/direct structure for response (report). Having a custom ability for report, ex report node1.custom_report();, might be better than just depending on access modifier (private, protect, public).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
jac cloud Issues related to the jac-cloud package
Projects
None yet
Development

No branches or pull requests

2 participants