Feature requests welcome

[Peter Knego]

If you think that Xmappr lacks a feature that you can't live without,
then let us know.

We might add this feature just to make you happy ;)

Peter Knego

[Pangea]

Will a lazy parsing of the elements be supported. i.e. the
<address> element should only be parsed on the first call to
"getAddress()" method.

[Peter Knego]

There are two obstacles to implementing this:

1. XML data comes as stream of bytes (or chars) and there is no random access to elements as there is with databases. Lazy parsing would therefore have to parse the whole stream every time an access to a new element would be made. This would negatively affect performance and would negate the whole purpose of lazy loading.
2. The produced objects would have to be either proxied or their bytecode would have to be enhanced. This are techniques currently employed by ORM tools to support lazy-loading (and write-on-change). Both of this techniques have drawbacks and produce a new set of problems.

Given this, there is no plan to support this feature in Xmappr.

Peter

[Pangea]

1. my 2 cents to convinvince u for this feature...;-). If we can store
the DOM (light weight like dom4j or jdom) model then we can use xpath
to randomly retrieve that data right. I know dom can be built only
aftera sinle parsing is done but still its just going to be 1 single
parse...and yes we have to maintain the DOM in memory but don4j being
leightweight that is ok.

2. i guess this response is for caching. i can live without it ;-)

On Jan 6, 2:38 pm, Peter Knego <pe...@knego.net> wrote:
> There are two obstacles to implementing this:
>
> 1. XML data comes as stream of bytes (or chars) and there is no random
> access to elements as there is with databases. Lazy parsing would therefore
> have to parse the whole stream every time an access to a new element would
> be made. This would negatively affect performance and would negate the whole
> purpose of lazy loading.
> 2. The produced objects would have to be either proxied or their bytecode
> would have to be enhanced. This are techniques currently employed by ORM
> tools to support lazy-loading (and write-on-change). Both of this techniques
> have drawbacks and produce a new set of problems.
>
> Given this, there is no plan to support this feature in Xmappr.
>
> Peter
>

[Peter Knego]

1) DOM and XPath are slower than Xmappr, so creating an intermediate step where we "cache" XML into DOM would not be faster as Xmappr alone. Xmapprs also uses "single parse", i.e. it produces an object tree in one go.
I plan to do some serious benchmarking in the next month or so. I'll create a separate project with source code et all for anyone to inspect/contribute.

2) I didn't mean caching. Lazy loading (producing objects late, obly when getters/.setters are invoked) in Java can be only achieved via class proxies or via bytecode enhancement (as far as I know).

[Pangea]

There are systems from which we receive large xmls and 50% of it is
numeric data (average xml may contain 5000 data items). Parsing is
inevetiable so lets ignore it. The problem is, converting those those
50% numeric fields to their corresponding type eagerly. Out of those
50% the client might only use < 1% of the data in decisioning rules.
We have very stringent performance requirements so we avoid eager type
conversion.

[Peter Knego]

This can be solved by mapping numeric data to field of type String and perform conversion in getter/setter. So conversion would only be done when data is accessed by client.

Can you give me an example XML and class to map to?

Also remember that premature optimization is evil ;) First test Xmappr with some real data and then assess if it's fast enough and if optimization is needed.

Peter

[Pangea]

sure i will give this a try...regarding premature optimization...these
decsions were based upon our past 4 years of experience after coding
60+ integration projects. more than half of them are xml based...

On Jan 6, 5:52 pm, Peter Knego <pe...@knego.net> wrote:
> This can be solved by mapping numeric data to field of type String and
> perform conversion in getter/setter. So conversion would only be done when
> data is accessed by client.
>
> Can you give me an example XML and class to map to?
>
> Also remember that premature optimization is evil ;) First test Xmappr with
> some real data and then assess if it's fast enough and if optimization is
> needed.
>
> Peter
>

[Peter Knego]

When I said premature optimization I meant that you should try Xmappr first on a set of your real data, compare results with other technologies you are using now (dom4j, etc..) and if results are not satisfactory only then start looking for bottlenecks in Xmappr and optimize those.

I'd be glad to help you go through this process. Just let me know.

Peter