-1L Sort Field Value in Mongodb With Spring Boot-CodePudding

I came across a solution when I was working on a basic join within an aggregation pipeline.

The Solution's Code Snippet:

public Document getMovie(String movieId) {
        if (!validIdValue(movieId)) {
            return null;
        }
        
        List<Bson> pipeline = new ArrayList<>();
        // match stage to find movie
        Bson match = Aggregates.match(Filters.eq("_id", new ObjectId(movieId)));
        pipeline.add(match);
        // TODO> Ticket: Get Comments - implement the lookup stage that allows the comments to
        // retrieved with Movies.
        pipeline.addAll(Arrays.asList(new Document("$lookup",
                new Document("from", "comments")
                        .append("let",
                                new Document("id", "$_id"))
                        .append("pipeline", Arrays.asList(new Document("$match",
                                        new Document("$expr",
                                                new Document("$eq", Arrays.asList("$movie_id", "$$id")))),
                                new Document("$sort",
                                        new Document("date", -1L))))
                        .append("as", "comments"))));
        
        Document movie = moviesCollection.aggregate(pipeline).first();
        
        return movie;
    }

I am simply wondering what was the purpose of -1L in this case? As the tests have already passed with only -1 value.

I tried searching for it but in vain.

The Tests Code Snippet:

@SuppressWarnings("unchecked")
  @Test
  public void testGetMovieComments() {
    String movieId = "573a13b5f29313caabd42c2f";
    Document movieDocument = dao.getMovie(movieId);
    Assert.assertNotNull("Should not return null. Check getMovie()", movieDocument);

    List<Document> commentDocs = (List<Document>) movieDocument.get("comments");
    int expectedSize = 147;
    Assert.assertEquals(
        "Comments list size does not match expected", expectedSize, commentDocs.size());

    String expectedName = "Arya Stark";
    Assert.assertEquals(
        "Expected `name` field does match: check your "   "getMovie() comments sort order.",
        expectedName,
        commentDocs.get(1).getString("name"));
  }

Thank you.

CodePudding user response：

Is this not simply a Java convention?

The L suffix tells the compiler that we have a long number literal.

Java byte, short, int and long types are used do represent fixed precision numbers.q This means that they can represent a limited amount of integers

from: https://zetcode.com/java/data-type/#:~:text=The L suffix tells the,type can represent is 9223372036854775807.

As these are values are ultimately being collated into a request to Mongo, I don't think it should really make a difference in this instance as there would be not difference in the type instances sent to Mongo. I'm sure you could look in the MongoDriver code and see this fairly easily. I may link it.