Skip to content

fix #2368 by fixing the underlying problem that scalars should be easier #2372

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.

Sign up for GitHub

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

Jump to bottom
Merged
Mpdreamz merged 4 commits into from
Nov 18, 2016
Merged

fix #2368 by fixing the underlying problem that scalars should be easier #2372

Mpdreamz merged 4 commits into from
Nov 18, 2016

Conversation

@Mpdreamz
Copy link
Member

@Mpdreamz Mpdreamz commented Nov 4, 2016

... to map inside the fluent properties descriptor

.Properties(ps => ps
 	.Scalar(p => p.Int, m => m)
 	.Scalar(p => p.IntNullable, m => m)
 	.Scalar(p => p.Float, m => m)
 	.Scalar(p => p.FloatNullable, m => m)
 	.Scalar(p => p.Char, m => m)
 	.Scalar(p => p.CharNullable, m => m)
 	.Scalar(p => p.Guid, m => m)
///snip 	
	.Scalar(p => p.String, m => m)
 );

gmarz
gmarz reviewed Nov 4, 2016
View reviewed changes
Copy link
Contributor

@gmarz gmarz left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there a reason we can't overload Number() and Date() rather than introducing Scalar()?

@Mpdreamz
fix #2368 by fixing the underlying problem that scalars should be eas…
f2b6400 
…ier to map inside the fluent properties descriptor
@Mpdreamz Mpdreamz force-pushed the fix/easier-scalar-mappings branch from 37c70d7 to f2b6400 Compare November 4, 2016 19:37
@Mpdreamz
Copy link
Member Author

Mpdreamz commented Nov 4, 2016

@gmarz I quite like the separate Scalar route with overloads .Number(n=> would be amiguous until either its closed by ) or you type ,.

The other reason i quite like Scalar is that in fluent mapping it doesn't flow too well you have to know what type you are going to target before specifying the name.

With .Scalar( you can simply map 90% of the properties in a much more exploratory friendly way.

@russcam
Copy link
Contributor

russcam commented Nov 10, 2016

Check CLS Compliance for this

russcam
russcam reviewed Nov 10, 2016
View reviewed changes
src/Nest/Mapping/Types/Properties-Scalar.cs Outdated
SetProperty(selector?.InvokeOrDefault(new KeywordPropertyDescriptor<T>().Name(field)));

public PropertiesDescriptor<T> Scalar(Expression<Func<T, string>> field, Func<TextPropertyDescriptor<T>, ITextProperty> selector) =>
SetProperty(selector?.InvokeOrDefault(new TextPropertyDescriptor<T>().Name(field)));
Copy link
Contributor

@russcam russcam Nov 10, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This should do the same thing as string inference on automapping i.e. add a keyword multi_field

@russcam
Copy link
Contributor

russcam commented Nov 10, 2016

Add IEnumerable overloads

@gmarz
Copy link
Contributor

gmarz commented Nov 11, 2016

@forloop I added IEnumerable overloads with my last commit. Mind giving this a final review?

russcam
russcam previously requested changes Nov 17, 2016
View reviewed changes
Copy link
Contributor

@russcam russcam left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just one comment, otherwise LGTM

src/Nest/Mapping/DynamicTemplate/SingleMapping.cs Outdated

#pragma warning disable CS3001 // Argument type is not CLS-compliant
public IProperty Scalar(Expression<Func<T, int>> field, Func<NumberPropertyDescriptor<T>, INumberProperty> selector) =>
selector?.InvokeOrDefault(new NumberPropertyDescriptor<T>().Name(field).Type(NumberType.Integer));
Copy link
Contributor

@russcam russcam Nov 17, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think all of these should be

selector.InvokeOrDefault(...)

if selector is null, we want to return the default, but the null conditional on the .InvokeOrDefault() will return null if selector is null.

Copy link
Member Author

@Mpdreamz Mpdreamz Nov 18, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yep! good catch will fix these now.

@Mpdreamz Mpdreamz dismissed russcam’s stale review November 18, 2016 11:51

Handled remaining comment

@Mpdreamz Mpdreamz merged commit 345eb8d into master Nov 18, 2016
Mpdreamz added a commit that referenced this pull request Nov 18, 2016
@Mpdreamz
fix #2368 by fixing the underlying problem that scalars should be eas…
bc9f647 
…ier (#2372)

* fix #2368 by fixing the underlying problem that scalars should be easier to map inside the fluent properties descriptor

* remove compiler warnings

* Add IEnumerable overloads

* selector?.InvokeOrDefault => selector.InvokeOrDefault
@Mpdreamz
Copy link
Member Author

Mpdreamz commented Nov 18, 2016

merged to master and 5.x

@Mpdreamz Mpdreamz deleted the fix/easier-scalar-mappings branch November 30, 2016 16:58
awelburn pushed a commit to Artesian/elasticsearch-net that referenced this pull request Nov 6, 2017
@Mpdreamz
fix elastic#2368 by fixing the underlying problem that scalars should…
6b9deb8 
… be easier (elastic#2372)

* fix elastic#2368 by fixing the underlying problem that scalars should be easier to map inside the fluent properties descriptor

* remove compiler warnings

* Add IEnumerable overloads

* selector?.InvokeOrDefault => selector.InvokeOrDefault
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

2 more reviewers

@gmarz gmarz gmarz left review comments

@russcam russcam russcam left review comments

Reviewers whose approvals may not affect merge requirements

Assignees

@gmarz gmarz

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

4 participants

@Mpdreamz @russcam @gmarz