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

Unable to force property order when saving document [DATAMONGO-172] #1108

Closed
spring-projects-issues opened this issue Jun 9, 2011 · 4 comments
Closed
Assignees
Labels
in: mapping type: bug
Milestone

Comments

@spring-projects-issues
Copy link

@spring-projects-issues spring-projects-issues commented Jun 9, 2011

Andrew Serff opened DATAMONGO-172 and commented

I have a Location object that I need to force the order of the properties when they get persisted to mongodb so that I can set a GeoSpatialIndex on the field. In order to use the GeoSpatialIndex, the first two properties must be numbers (lat/lon). In my case, I have the following object:
Location {
float lat;
float lon;
County county;
}
When the Location object is persisted in mongodb, it puts the properties in alphabetical order. So I tried adding:
@XmlRootElement(name="location")
@XmlType(propOrder={"latitude", "longitude", "county"})

but this doesn't work either. I was asked to enter a JIRA for the issue.

I'm about to try to use a custom Converter which I assume is a workaround to the issue (I hope). It would be very nice if using the annotation (or a different one) would work though. It would be much more simple.

If the workaround doesn't work and there isn't another work around, this is a very major issue because I can't create a geospatial index the way it works.


Affects: 1.0 M3

Reference URL: http://forum.springsource.org/showthread.php?110425-Force-property-order-in-MongoDB-mapping&p=366345

Attachments:

Issue Links:

  • DATACMNS-50 Extend mapping metadata to allow defining order of PersistentProperties
    ("depends on")
  • DATAMONGO-152 Investigate failing of test for repository.findbyLocationWithinBox
@spring-projects-issues
Copy link
Author

@spring-projects-issues spring-projects-issues commented Jun 9, 2011

Andrew Serff commented

Ok, so I tried the converter but I ran into a problem with it being able to convert the nested County object. But I ran into a larger issue. Even if the converters work, the MongoTemplate constructors only allow for either setting the Converters OR setting a UserCredential object, not BOTH. Cloudfoundry requires username/password to be used when connecting to MongoDB, so I have to be able to set the UserCredentials object. So either there either needs to be setters for the UserCredentials and the Converters or a new constructor that takes both. Right now, I'm unable to persist the object in a way that will let me use a geospatial index. Any idea when this would get fixed even in a nightly build? I may take a stab at adding the setters for the properties needed and push you a fix if I get time.

@spring-projects-issues
Copy link
Author

@spring-projects-issues spring-projects-issues commented Jun 10, 2011

Thomas Risberg commented

We could potentially use the @Order annotation that already exists in Spring.

@Order(1)
float lat;
@Order(2)
float lon;
County county;

@spring-projects-issues
Copy link
Author

@spring-projects-issues spring-projects-issues commented Jun 13, 2011

Oliver Drotbohm commented

Hi Andrew, thanks for bringing this up. Have you tried using a wrapper class (e.g. named Point) that holds a float[] as workaround? This should lead to something like this:

class Location {
  Point point;
  Country country;
}

class Point {
  float[] coordinates;
}

That should make the code unaffected by any order issues. The query would be

db.collection.find({"location.point" : {"$near" : [40, -73]} })

Unfortunately our implementations of Point, Box and Circle use properties instead of arrays right now so that the order of persisting properties suddenly becomes an issue. We probably will change those implementations to use arrays instead of properties

@spring-projects-issues
Copy link
Author

@spring-projects-issues spring-projects-issues commented Jul 6, 2011

Oliver Drotbohm commented

Should be fixed and available in tonight's snapshot. We dropped @FieldName over a more generic @Field that has an order attribute. All properties annotated this way will be ordered according to the attribute value followed by all unannotated properties in undetermined order. We've also annotated our domain abstractions (e.g. Box, Point etc.) to carry this annotation

@spring-projects-issues spring-projects-issues added type: bug in: mapping labels Dec 30, 2020
@spring-projects-issues spring-projects-issues added this to the 1.0 M4 milestone Dec 30, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
in: mapping type: bug
Projects
None yet
Development

No branches or pull requests

2 participants