0 votes

You could add a global search : locate what parameter is generating in kind of data we identify in the entities : that would help for debugging purposes.

By global search I meant allow to search everywhere in the skipper file. For example, when I do an export to my ORM, I might misdesign some elements (wrong data-type, wrong parameter, wrong path) and the way I figure this out is when I receive an error message either from my ORM, from SQL, from the profiler or anything else. This error often relates to code written by Skipper. So to revert the changes in the skipper model before I make a new export, it would be nice to identify what in skipper generated this code.

An example : I imported my mysql workbench scheme with some fields having the unsigned property. This lead to an error when exporting the data to my ORM. Instead of checking all the errors from within my ORM, I would have liked to type “unsigned” in the search bar above the modules in order to list all fields having the property unsigned and changed them to “option unsigned=true”. The same would have helped me find faster where I put the wrong namespace, etc.

in Feature Request by Skipper developer (141k points)

Please log in or register to answer this question.