Object-Entity Mapping (OEM)

[shaobo-he-aws]

Rendered

[john-h-kastner-aws]

produces an entity uid unless the type is annotated with the #[cedar(transparent)] clause

I would rather see this made more explicit. E.g., #[cedar(record)] or #[cedar(entity)], perhaps with the entity case being assumed by default.

This could also support a nice syntax like #[cedar(long)] struct MyLong(i32) for wrapper types that might exist.

[khieta]

Thanks for the writeup @shaobo-he-aws! I think this looks like a useful addition to Cedar, but I disagree that it should be an RFC. It's a change to the Rust API rather than the Cedar language, so I think it should remain as an issue in the cedar repository. Maybe you could move the details here into cedar#986?

How do others feel about an RFC vs. issue here?

[shaobo-he-aws]

Thanks for the writeup @shaobo-he-aws! I think this looks like a useful addition to Cedar, but I disagree that it should be an RFC. It's a change to the Rust API rather than the Cedar language, so I think it should remain as an issue in the cedar repository. Maybe you could move the details here into cedar#986?

How do others feel about an RFC vs. issue here?

I'm afraid that moving it to an issue reduces discussion and eventually makes it buried in the backlog list.

[cdisselkoen]

It's a change to the Rust API rather than the Cedar language, so I think it should remain as an issue

We've previously done RFCs for other major changes that aren't technically changes to the Cedar language itself, for example, RFC 32 and arguably RFC 8. Similarly, I think there is consensus that partial evaluation itself would have been an RFC except that its development predates the RFC process. I think that this is a major enough change that an RFC is warranted, and particularly since @shaobo-he-aws has already gone to the trouble of writing one up, I think it makes sense to treat it as an RFC. If we didn't already have an RFC writeup and the primary author was pushing hard to keep this an issue instead of an RFC, I could see us maybe making a different decision on RFC vs issue, but since in this case the primary author is welcoming the RFC process, I see no reason to deny that.

I'm afraid that moving it to an issue reduces discussion and eventually makes it buried in the backlog list.

Even getting an RFC accepted (into Active state) does not promise any particular implementation priority, and the resulting implementation issue could easily get no discussion and become buried in the backlog, like, for example, RFC 53, where it took almost 3 months for the implementation issue to even be made. The RFC process isn't a magic way to get implementation prioritized, vs any other issues in the backlog. See the RFC life-cycle.

[B-Lorentz]

What about a trait that would allow an user-provided struct to be borrowed as an entity/context?

Something like

trait AsEntity {
    pub fn uid(&self) -> EntityUID;

    pub fn get(&self, attr: &str) -> Option<&AsPartialValue>;
   
    
    pub fn get_tag(&self, tag: &str) -> Option<&AsPartialValue>;

   pub fn ancestors -> Impl<Iterator....
   // whatever other things the evaluator could want to know.
}

or the same with Result return types.

Basically you could implement this trait if you have a type that you know its representing an entity, whatever its internal structure is (it could be a serde_json::Value, your own struct, whatever), and the evaluator could use it to try to view it as one, without necessarily needing to allocate an actual owned 'Entity' structure.

At first, this api would be provided by the evaluator in fact aggressively converting to Entity, but later the conversion could be optimized away.

This wouldn't of course matter for use over the network, but could make it more seamless to integrate cedar directly to a rust codebase.

One might chose to then implement this manually, and the macros originally mentioned in the rfc would implement this too, instead of Into

[shaobo-he-aws]

What about a trait that would allow an user-provided struct to be borrowed as an entity/context?

Something like

trait AsEntity {
    pub fn uid(&self) -> EntityUID;

    pub fn get(&self, attr: &str) -> Option<&AsPartialValue>;
   
    
    pub fn get_tag(&self, tag: &str) -> Option<&AsPartialValue>;

   pub fn ancestors -> Impl<Iterator....
   // whatever other things the evaluator could want to know.
}

or the same with Result return types.

Basically you could implement this trait if you have a type that you know its representing an entity, whatever its internal structure is (it could be a serde_json::Value, your own struct, whatever), and the evaluator could use it to try to view it as one, without necessarily needing to allocate an actual owned 'Entity' structure.

At first, this api would be provided by the evaluator in fact aggressively converting to Entity, but later the conversion could be optimized away.

This wouldn't of course matter for use over the network, but could make it more seamless to integrate cedar directly to a rust codebase.

One might chose to then implement this manually, and the macros originally mentioned in the rfc would implement this too, instead of Into

This is a good idea. Do you mind writing up a RFC for it?

[B-Lorentz]

What about a trait that would allow an user-provided struct to be borrowed as an entity/context?
Something like

trait AsEntity {
    pub fn uid(&self) -> EntityUID;

    pub fn get(&self, attr: &str) -> Option<&AsPartialValue>;
   
    
    pub fn get_tag(&self, tag: &str) -> Option<&AsPartialValue>;

   pub fn ancestors -> Impl<Iterator....
   // whatever other things the evaluator could want to know.
}

or the same with Result return types.
Basically you could implement this trait if you have a type that you know its representing an entity, whatever its internal structure is (it could be a serde_json::Value, your own struct, whatever), and the evaluator could use it to try to view it as one, without necessarily needing to allocate an actual owned 'Entity' structure.
At first, this api would be provided by the evaluator in fact aggressively converting to Entity, but later the conversion could be optimized away.
This wouldn't of course matter for use over the network, but could make it more seamless to integrate cedar directly to a rust codebase.
One might chose to then implement this manually, and the macros originally mentioned in the rfc would implement this too, instead of Into

This is a good idea. Do you mind writing up a RFC for it?

I would be happy to, when I find the time.
But ultimately, it would require a nontrivial rework of the evaluator internals, to truly take advantage of this, efficency-wise

[B-Lorentz]

What about a trait that would allow an user-provided struct to be borrowed as an entity/context?
Something like

trait AsEntity {
    pub fn uid(&self) -> EntityUID;

    pub fn get(&self, attr: &str) -> Option<&AsPartialValue>;
   
    
    pub fn get_tag(&self, tag: &str) -> Option<&AsPartialValue>;

   pub fn ancestors -> Impl<Iterator....
   // whatever other things the evaluator could want to know.
}

or the same with Result return types.
Basically you could implement this trait if you have a type that you know its representing an entity, whatever its internal structure is (it could be a serde_json::Value, your own struct, whatever), and the evaluator could use it to try to view it as one, without necessarily needing to allocate an actual owned 'Entity' structure.
At first, this api would be provided by the evaluator in fact aggressively converting to Entity, but later the conversion could be optimized away.
This wouldn't of course matter for use over the network, but could make it more seamless to integrate cedar directly to a rust codebase.
One might chose to then implement this manually, and the macros originally mentioned in the rfc would implement this too, instead of Into

This is a good idea. Do you mind writing up a RFC for it?

The RFC is here:
#93