Skip to content

Vehicle rental updates#3632

Merged
optionsome merged 19 commits into
opentripplanner:dev-2.xfrom
HSLdevcom:vehicle-rental-updates
Nov 2, 2021
Merged

Vehicle rental updates#3632
optionsome merged 19 commits into
opentripplanner:dev-2.xfrom
HSLdevcom:vehicle-rental-updates

Conversation

@optionsome

@optionsome optionsome commented Oct 5, 2021

Copy link
Copy Markdown
Member

Summary

  • Updates Smoove bike rental data source
  • Properly implements all bike rental station fields in the legacy GraphQL API
  • Adds allowPickup, allowPickupNow, allowDropoffNow and operative to the legacy GraphQL API
  • Updates file generation for the legacy GraphQL API

Issue

closes #3631

Unit tests

Updated tests

Code style

Have you followed the suggested code style?

Yes

Documentation

  • Updated sandbox documentation

Changelog

TODO

@optionsome optionsome requested a review from a team as a code owner October 5, 2021 07:48
@t2gran t2gran added this to the 2.1 milestone Oct 5, 2021
@t2gran t2gran added the +Sandbox This will be implemented as a Sandbox feature label Oct 5, 2021
@t2gran

t2gran commented Oct 5, 2021

Copy link
Copy Markdown
Member

I have looked at the core changes and those looks ok, so feel free to merge this when it is ready. We will update the Transmodel API after this get merged.

@leonardehrenfried

Copy link
Copy Markdown
Member

This looks good. I have a questions: does upgrading the codegen libs solve the problem of manually having to fix the enum code?

@hannesj

hannesj commented Oct 5, 2021

Copy link
Copy Markdown
Contributor

This looks good. I have a questions: does upgrading the codegen libs solve the problem of manually having to fix the enum code?

Yes, that was fixed in a recent version of the plugin

@optionsome

Copy link
Copy Markdown
Member Author

We discussed this on tuesday's meeting and decided that it's better if we split the floating vehicles into own query type in the GraphQL APIs. I'll do that for the legacy GraphQL API in the scope of this pr.

@optionsome

Copy link
Copy Markdown
Member Author

This looks good. I have a questions: does upgrading the codegen libs solve the problem of manually having to fix the enum code?

Noticed today that there are still some issues with enum type arguments that to my knowledge require editing the LegacyGraphQLTypes.java file manually. For example for the routes query arguments, the following code gets now generated:

if (args.get("transportModes") != null) {
    this.transportModes = (Iterable<LegacyGraphQLMode>) args.get("transportModes");
}

which needs to be edited to

if (args.get("transportModes") != null) {
    this.transportModes = ((List<String>) args.get("transportModes")).stream()
        .map(LegacyGraphQLMode::valueOf)
        .collect(Collectors.toList());
}

@optionsome optionsome left a comment

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

There is still only possible to filter by ids using "bikeRentalStations" in the nearest query. This could be changed but I'm not sure how often this functionality is even used. Also it would be nice if it was possible to filter nearest query so you would only get vehicles or stations.


if (args.getLegacyGraphQLIds() != null) {
ArrayListMultimap<String, VehicleRentalStation> vehicleRentalStations =
vehicleRentalStationService.getVehicleRentalStations()

@optionsome optionsome Oct 19, 2021

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

Should there be a helper method for getting only vehicles/stations in VehicleRentalStationService and/or should we store the vehicles and the stations in separate Maps there?

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

I think a helper method would suffice

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

Ok that's done now.

id: ID!

"""ID of the vehicle in the format of network:id"""
vehicleId: String

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

Should this id have a more generic term that could be shared between RentalVehicle and VehicleRentalStation?

hannesj
hannesj previously approved these changes Oct 19, 2021

@hannesj hannesj left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Looks good for the common code, minor comments for the sandbox.


if (args.getLegacyGraphQLIds() != null) {
ArrayListMultimap<String, VehicleRentalStation> vehicleRentalStations =
vehicleRentalStationService.getVehicleRentalStations()

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

I think a helper method would suffice

SelectionSet set = environment.getField().getFields().get(0).getSelectionSet();
boolean queryHasBikeRentalStationFragment = set != null && set.getSelections()
.stream()
.filter(selection -> selection instanceof InlineFragment)

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

What about FragmentDefinition?

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

Seems like we can only see the name of a FragmentDefinition from TypeResolutionEnvironment. So currently, we can't add support for deciding which object type to return based on those types of fragments so we will always return VehicleRentalStation. This breaks backwards compatibility a bit but we only use inline fragments for the nearest query in our UI so it's ok to have this problem for a while. I created an issue in graphql-java project about adding more information about fragments to the environment so this can be fixed later.

@optionsome

Copy link
Copy Markdown
Member Author

On Tuesday's discussion, we decided to evaluate if https://github.com/kobylynskyi/graphql-java-codegen could be used to replace the code generation based on the GraphQL schema but I won't do it in the scope of this pull request. I think this pull request is now ready for final review.

Comment thread src/ext/java/org/opentripplanner/ext/transmodelapi/TransmodelGraphQLSchema.java Outdated
Comment thread src/ext/java/org/opentripplanner/ext/transmodelapi/TransmodelGraphQLSchema.java Outdated
VehicleRentalStationService service = graph.getVehicleRentalStationService();
if (service == null) {return List.of();}
return service.getVehicleRentalStations()
return service.getVehicleRentalPlaces()

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

We should probably split this layer in two, so that they can be showed on different zoom levels. This can be done later

hannesj
hannesj previously approved these changes Oct 21, 2021
public ZonedDateTime lastReported;

// OTP internal data
public boolean allowOverloading = false;

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Add some JavaDoc to this.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

There is some javadoc in the VehicleRentalPlace for it. All fields here seem to be missing javadoc. There's currently no mention anywhere that this information is not in the GBFS spec but I'm not sure what would be the approriate place for it.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

You could just link to the VehicleRentalPlace in the class JavaDoc then. I try to avoid redundant documentation:

/** See {link VehicleRentalPlace}  ... */

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

Should that be done for this field and/or whole class and/or all fields/methods?

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

I added a couple of comments that link the implementing classes to the interface class.

@optionsome optionsome merged commit f72f1fb into opentripplanner:dev-2.x Nov 2, 2021
@optionsome optionsome deleted the vehicle-rental-updates branch November 2, 2021 20:43
t2gran pushed a commit that referenced this pull request Nov 2, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

+Sandbox This will be implemented as a Sandbox feature

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Unimplemented bike rental fields in legacy GraphQL API

4 participants