Dependencies: Reducing XML size about abaplint-sci-client HOT 13 CLOSED

Maybe gzip instead? I don't know if sap http automatically compresses requests. Guess, worth to check it.

At the same time, if sap can compress requests on http level, it would a lot more efficient than fiddling with compression on json content side...

Just thoughts

from abaplint-sci-client.

More thoughts. Some kind of class to strip xml would be very useful in abapgit for deployment - i have some ideas, id like to implement in that respect.

from abaplint-sci-client.

quick and dirty: #95

should do http compression, but currently we are battling some large files and the abaplint XML parser running out of memory

from abaplint-sci-client.

and yea, would be nicer if we could inject something to skip the serialization of DYNPROS, like longtexts

from abaplint-sci-client.

maybe something simple like a flag "minimal_serialization". After that all objects need to be reviewed (and adjusted) for minimal requirements needed for dependency checks.

from abaplint-sci-client.

might want to hide this behind some flags, good for later

from abaplint-sci-client.

and its quite slow

probably should do the injection trick, but it requires some refactoring in abapGit

from abaplint-sci-client.

I guess one flag will be not enough. It is not clear what is minimal, and it will mean different for different object types :)

My use case (maybe not directly relevant to this particular issue) is different:
while deploying from one system to another (e.g. non-Hana -> HANA) new stuff appear in XML, so many objects are always yellow. This is due to some specific XML parts. Which might be useful (not to skip them totally) ! But the are missing in original system, so I want to ignore them. Or another case - languages. So my idea was to build an XML postprocessor which would strip both local and remote XMLs before comparing them. And control it with some quick text xpath-like rules which could be entered right into UI e.g. exclude xml(tabl) /attr1/attr2

from abaplint-sci-client.

And then same mech. can be used to reduce xml for abaplint too

from abaplint-sci-client.

the scope for this issue is dependencies, ie. typically SAP standard code.

For the code "we" write keep as is

from abaplint-sci-client.

indeed it is quite different from a dependency perspective. One flag for this should be sufficient "only_dependency_requirements" :-) as it is for a specific use case.

Probably when we cover PROG, FUGR, CLAS, INTF we already made a big leap forward.
There might be some other easy wins like MSAG (no long texts) or forcing master language only for dependencies.

But also for this we need to be careful what we reduce as it might have impact in what is checked.
example Dynpro's: it the dynpro number checked? Are the dynpro fields needed for checks?

We might want to change the check behavior. "If an object that needs to be checked is part of an SAP original", then it is ok Syntax wise and we do not want to check the for coding styles. See #47.

from abaplint-sci-client.

note the checked object is serialized by native abapGit, the code in ZCL_ABAPLINT_DEPS_SERIALIZER handles serialization of dependencies which does not have errors reported directly

from abaplint-sci-client.

think this is done, closing

from abaplint-sci-client.