[3.1] Cache Question

[zpqrtbnk]

Hey,

It has to be obvious but I cannot understand it.

The MemberAccessor class creates get/set delegates. That happens when a PocoDataBuilder is initialized. Which seems to happen anytime a PocoDataFactory has to return a PocoData for a type for the first time. And each Database, when created, seems to create and own it own PocoDataFactory.

Which would mean that each Database instance ends up creating a data factory, builders, the get/set delegates, etc. Which sounds... bad.

What am I missing? ;-)

S.

[kersane]

@zpqrtbnk nice catch :), i just playing with NPoco to understand its internal mechanism, IMHO v3.1 introduce a lot of broken changes in its internal structure. I agree with you about PocoData that should be statically cached, but this behavior is intentionally changed since v2.11.10, any reason @schotime ?. There are also inconsistent behavior about using Attributes and FluentMapping especially for reference. Indeed v3.1 offer flexibility over mapping plan that is awesome in my opinion, but i think there are a lot of things that need to be clarified about those changes.

[zpqrtbnk]

Into PR mode ;-)

[schotime]

Hey guys,

There is indeed a caching issue that I'm working through at the moment.
It's quite complex so I'm trying to plan in out.

The pocodata's are rebuilt on each query now as they may need to mutate per
query, however they are very cheap to build. This is done to enable certain
scenarios with the linq queries.

Thanks for the feedback
Adam
On 10 Mar 2016 9:27 pm, "Stephan" [email protected] wrote:

Into PR mode ;-)

—
Reply to this email directly or view it on GitHub
#235 (comment).

[zpqrtbnk]

As I go through the code and try to understand and check changes vs v2, might submit PRs that mostly add comments, to begin with - if that's OK with you?

[kersane]

It is indeed quite complex :D, but i think once you traverse all member and built PocoData metadata is enough to support most query scenario, (except for dynamic, which need to be evaluated each run) or maybe i missed some scenario? My idea is moving PocoDataFactory outside the Database lifecycle and injected into database for mapping plan, therefore you can maintain static cache for typed poco, but im not sure if it is suitable for dynamic property.

[schotime]

That's what already happens with fluent config because you can have multiple configs but you can only have one attribute mapping so I think I have a solution. Bare with me.

[kersane]

@schotime about fluent mapping, have you read my comment #232 (comment) ?

[schotime]

@dwirawan I have, and its on my list to have a look at tomorrow after I sort the caching out ;)

[kersane]

@schotime thanks, maybe i will start some contribution for small patch, since i am not familiar with git, so pardon me for some PR mistake ;)

[schotime]

@dwirawan Even if you can figure out the problem and can send me the snippet that fixes and a test or post it in the issue then I can always patch it from there ;)

[schotime]

Just committed up new changes and merged your other PR @zpqrtbnk

[schotime]

This one fixed now? Can i close?

[zpqrtbnk]

From what I've seen, using the new fluent factory et al, my original question is solved. Thanks!
Closing.