Is there a way to go without mappings. about archelix-rsql

I guess it would be nice if there is some automatic path mapping by default with some configuration.
I have some sample code that can generate a map of paths (type -> QEntity.entity.type) for a entity class. (https://github.com/gniding/spring-data-rest-webmvc/blob/master/src/main/java/org/springframework/data/rest/example/common/BaseRepositoryImpl.java)

    void prepareFieldMap(Path<?> path, Map<String, Path> pathMapping, String prefix, int additionalLevels)
            throws IllegalArgumentException, IllegalAccessException {
        for (Field fld : FieldUtils.getAllFields(path.getClass())) {
            if (Modifier.isPublic(fld.getModifiers()) && !Modifier.isStatic(fld.getModifiers())
                    && Path.class.isAssignableFrom(fld.getType())) {
                pathMapping.put(prefix + fld.getName(), (Path<?>) fld.get(path));
                if (additionalLevels > 0 && fld.getType().getSimpleName().startsWith("Q")) {
                    prepareFieldMap((Path<?>) fld.get(path), pathMapping, prefix + fld.getName() + ".",
                            additionalLevels - 1);
                }
            }
        }
    }

        Map<String, Path> pathMapping = new HashMap<>();
        prepareFieldMap(QEntity.entity, pathMapping, "", 2);

[vineey]

@pacitu

I always need to map type -> QEntity.entity.type, type.value -> QEntity.entity.type.value, etc.
Is there a way to not explicitly specify all mappings as I want this to work for all class properties and paths and I have many entities.

Hi, not really sure if I understand you, but I'm guessing that you want to have a defaults for the ff. querydsl mappings:

1.) PATH Mapping - refers to the mapping from rql string to Querydsl QClass fields.
2.) JOIN Mapping - refers to the mapping of JOINED associations from the Child QClass field to the Parent QClasses.(also reusable for mongodb on DBRef)

Thus for each QClass, you don't have to manually specify it always. Probably certain use cases where you want to override the default, then you can specify the mappings.

I can create a module that implements runtime-generated default PATH and JOIN Mapping, from parent QClass. Then use caching for performance.

I can easily create a method that generates from a string a class path through reflection but I'll need the mapping object to be a closure that takes (String path, Class qclass ) and return the Path object instead of a static Map.

I don't get you here. Care to elaborate? Thanks for your feedback.

[vineey]

@gniding Thanks for sharing the code! Will look into this one and see how can we make things simplier.

[pacitu]

Yep gniding has a solution, but in my use case, I don't have the QClasses generated when my controllers are being compiled so I can't use them directly, I need to access them at runtime through reflection, I could try to restructure the build so the QClasses get generated before the rest of the app is compiled, but we'll probably wont do it. Anyway, my point was, that currently QuerydslFilterParam has a static map with mappings, which is used in the QuerydslRsqlVisitor::visit to get the Path objects from the string paths and I propose this conversion could be either dynamic by default and overwriteable with a static map or QuerydslFilterParam can have a function(closure) as attribute which calculates the Path objects and I can pass it to QuerydslFilterParam's constructor and customize however I need.
Example usage:

Predicate predicate = new DefaultFilterParser().parse(filter, withMapping(ReflectionUtils::pathMapper, customMappingsMap));

Where pathMapper is a static util method that calculates Path object based on a string path and customMappingsMap is a Map with mappings that don't follow the convention if any. So in the QuerydslRsqlVisitor::visit we can use the customMappingsMap and if the path is not in there then use the pathMapper closure to calculate the Path object to use.

[vineey]

@pacitu Now I do understand your situation at a higher level, but not concretely with regards to the compile phase stuff issue of QClasses. QClasses are generated on a phase after compile called generate-source phase. This is true both in gradle and maven build tools.

Meanwhile, what gniding wants and what I can see as good solution still fits your needs. Actually I don't need to add a closure(or Lambda Function in Java8) as parameter in the parser. But if you really need some kind of function, then before creating the QuerydslFilterParam, you can execute that function to dynamically generates the Map<String,Path> based on Root Entity. Then you can pass the result to the QuerydslFilterParam.

We can design that there will be default Map<String,Path> for every QClasses, and the Mappings passed to QuerydslFilterParam will override those of defined in the defaults. So if you pass an empty Map, then it means, the parser will use the defaults completely. If you pass an unempty Map but don't defined a certain PATH in the custom Map, then automatically the one defined in the defaults for that PATH will be used.

An issue that I can see is how can we allow to specify if we want to exclude a certain path in the default mappings. Excluding a PATH means, we don't allow it to be used in the rql, thus it will ignore the PATH in the defaults. This can be solved by adding another builder method that accepts configurations in the new DSL builder (#25) that we are going to develop for 3.0.0.

[pacitu]

@vineey @gniding 10x for the support I had the job done using @gniding path map generation. I had to workaround two issues first was I can't use the lib when searching inside of lists ( an entity having a list of strings as attribute stored in mongo ), and I couldn't make it work to find @DbRefed objects by their id, but I have workarounds for now. So 10x, looking forward to new features, I'm interested to contributing to this lib so you can ping me if I can help in any way.

[vineey]

@pacitu @gniding Once I'm done with the refactoring and dsl feature, #25, will push it on develop, I'm planning to finish it this weekends. Then other features can be delegated to other contributors. Will let you know, thank you very much for your feedback and support!

[vineey]

@pacitu While im fixing #113 to support query by DbRefed objects, can you own this ticket and just send your pull request later? I'm done with #25, so please rebase on develop branch to get the latest refactored code. Then apply your suggested changes.

Thanks for the contribution, highly appreciated!