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

Allow a serializer to be specified when ignoring an attribute #1352

Closed
wants to merge 3 commits into from
Closed

Allow a serializer to be specified when ignoring an attribute #1352

wants to merge 3 commits into from

Conversation

rjmcguire
Copy link

No description provided.

@s-ludwig
Copy link
Member

What worries me a little is that this connects a certain type to an output format. After all, a JSON serializer could output Json, string, std.json : JSON or any other type. Another potential issue is that it may actually be required to ignore different fields for the same format in different situations (e.g. when serializing a structure once for the DB and once for a REST API, but both times to JSON).

So taking that into account, maybe we could instead connect this to a certain serialization policy (serializeWithPolicy):

struct RESTPolicy {} // no additional customization in this policy

struct MyStruct {
    @ignore!RESTPolicy BsonObjectID _id;
    string foo;
    int bar;
}

The policy could maybe also support to encode this outside of the original struct declaration:

struct RESTPolicy {
    enum isIgnored(S, string fieldname) = is(S == MyStruct) && fieldname == "_id";
}

struct MyStruct {
    BsonObjectID _id;
    string foo;
    int bar;
}

This would mean that for it to be useful a few places, such as the MongoDB driver and the REST interface generator, would have to get means to customize the serialization process, but that is a rather important thing to support anyway.

@rjmcguire
Copy link
Author

On Thu, Dec 17, 2015 at 11:05 AM, Sönke Ludwig notifications@github.com
wrote:

What worries me a little is that this connects a certain type to an output
format. After all, a JSON serializer could output Json, string, std.json
: JSON or any other type. Another potential issue is that it may actually
be required to ignore different fields for the same format in different
situations (e.g. when serializing a structure once for the DB and once for
a REST API, but both times to JSON).

Agreed, it would be an issue if you used the same format in two places and
want different filtering.

So taking that into account, maybe we could instead connect this to a
certain serialization policy (serializeWithPolicy):

struct RESTPolicy {} // no additional customization in this policy

struct MyStruct {
@ignore!RESTPolicy BsonObjectID _id;
string foo;
int bar;
}

The policy could maybe also support to encode this outside of the original
struct declaration:

struct RESTPolicy {
enum isIgnored(S, string fieldname) = is(S == MyStruct) && fieldname == "_id";
}

struct MyStruct {
BsonObjectID _id;
string foo;
int bar;
}

This would mean that for it to be useful a few places, such as the MongoDB
driver and the REST interface generator, would have to get means to
customize the serialization process, but that is a rather important thing
to support anyway.


Reply to this email directly or view it on GitHub
#1352 (comment)
.

Nice, that would be better. Would it be a lot more changes in serializer.d
compared to the changes in this PR?
I didn't like having to tag the different Serializer drivers with the type
they output. It was just the shortest path for my needs.

s-ludwig added a commit that referenced this pull request Feb 23, 2016
This makes @ignore conditional per serialization policy.
@s-ludwig
Copy link
Member

See PR #1438.

@s-ludwig s-ludwig closed this in 50ee6b9 Feb 27, 2016
s-ludwig added a commit that referenced this pull request Feb 27, 2016
…lization-policy

Make all serialization attributes specifiable per policy. Fixes #1352.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants