Data Cache

[rubenalves]

Data cache - to be re-implemented

Any news if this will be ported from 1.9.

[rivantsov]

Hi and Happy New Year. yes, it will be ported, just not sure when I'll come to this, I planned to do some internal DataRecord refactorings (values storage and all that) to prepare it for Authorization and DataCache reimplementation. I hope it is not that critical for you now; worst case you can hand code caching some recordsets as objects

[rubenalves]

Happy New Year.

I tis not very critical bur in applications thar are open for dayes it sometimes gives errors, and in production i canot sse the complete stack and se where the problema realy resides. I have like 99% of it resolved.

How do recomend cahimg recordsets as objects?

Regards.

Com os melhores cumprimentos,

Ruben Alves Móvel: 916887379 Email: @.**@.>

De: Roman Ivantsov @.> Enviada: 31 de dezembro de 2021 06:55 Para: rivantsov/vita @.> Cc: rubenalves @.>; Author @.> Assunto: Re: [rivantsov/vita] Data Cache (Issue #203)

Hi and Happy New Year. yes, it will be ported, just not sure when I'll come to this, I planned to do some internal DataRecord refactorings (values storage and all that) to prepare it for Authorization and DataCache reimplementation. I hope it is not that critical for you now; worst case you can hand code caching some recordsets as objects

— Reply to this email directly, view it on GitHubhttps://github.com/rivantsov/vita/issues/203#issuecomment-1003300267, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AB7ISPTMYDMDY6XKW3F6AQDUTVOV3ANCNFSM5K2LYVFA. Triage notifications on the go with GitHub Mobile for iOShttps://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Androidhttps://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub. You are receiving this because you authored the thread.Message ID: @.**@.>>

[rubenalves]

My response was terrible. Sorry. O am sending it again with the text a little more readable.

Happy New Year.

It is not very critical but in applications that are open for dayes it sometimes gives errors, and in production i canot see the complete stack and find where the problema realy resides. I have like 99% of it resolved.

How do you recomend cashing the recordsets as objects?

Regards.

[rivantsov]

oh, no, nothing wrong with your post, sorry - my fault, got suck up into routine and did not respond on time. As for errors happening after app is running for days... what is the indication? you say there's no stack but at least error message? One thing to look at is memory/cpu/network usage; watch it (with task manager if possible), see if mem grows until crash, smth like that About caching. Well, nothing fancy, but requires some coding effort. Like you have list of European countries; each has Id and Name and some other stuff; Other tables reference it by Id; like Address table has column CountryId. So you load all countries into a list of Tuples; when you need to assign a country, you find a country by name in a list (or you already have a CountryId from UI dropdown selection). So to assign the id, you do:

address.Country = session.GetEntity(countryId, LoadOptions.Stub);

With stub option the session will NOT go to database to lookup country; it will lookup in cached list in session if Country is already loaded; if not, it will create a stub entity; the whole purpose here is to assign address.CountryId, but this Id is not exposed on entity, so you use this workaround with stub entity.

[rubenalves]

O think i found the problem in my app, or atleast part of it.

Is there any way i can force vita to force update a field in a table? I have a workaround with vita to ensure that the value is saved to the database.

It works like 99% of the times but if i can mark it to be saved on savechanges it wold be gold :) It must a little bug since vertion 2+ because on 1.9 that never happened.

Can it be something about PropertyChanged not getting fired?

Thanks.

[rivantsov]

I have some guess what might be going on, since you mentioned that in v1.9 it worked, but in current version it does not. The difference might be that in 1.9 SaveChanges used stored procedures to save the record. So update stored proc was updating all columns, even if 1 column/prop actually changed. In current version, system builds dynamic SQL to update only columns that have changed. System detects what columns changed by checking EntityRecord.ValuesModified value, if it is not null. Additionally, when app modified some prop, the code checks if new value is different from current in the record; if value is the same, it skips assignment. As a result, my guess, assigning a single value which is the same as old might not register record as modified. This is my guess. I suspect you assign a single prop value and sometimes do not see record updated. Pls provide more info on the suspect column (type and purpose) and what you're trying to do with an entity from biz logic point

[rubenalves]

it may be that.

It happens in my POS system, when there is a list of orders, and when i add the same product again the sistem locates the line in the list and just changed the quantity (decimal) column and saveschanges. 99% of the times it saves the dada but some times it does not commit the changes.

In the solution that i have now i savechanges with vita, and with dapper and then reload the data again with vita.

Can i force the quantity column to always save?

Thanks for your time.

[rubenalves]

If i use something like this

linha.quantity = 1.5; EntityHelper.GetRecord(linha).Status = EntityStatus.Modified; Sessao.SaveChanges();

Does vita save the changes even if the values are the same?

[rivantsov]

'... if values are the same..' - that might be the problem; when you assign the value, the code checks if it is different from current value in Db; if it is the same, the call is ignored; Modified values are written to a separate array, ValuesModified, and on SaveChanges the SQL is built from values in ValuesModified. So if the value is the same on assignment, no value is posted to ValuesModified, nothing to update. Let me look again at the code, I will let you know

[rivantsov]

using dapper for extra saving - that's too much. I thought you got rid this stuff. Did you check it's not another database trigger? :( Instead of setting status explicitly, I would suggest to do assignment twice, with different values, to try to workaround the check 'if value is the same, skip it'; something like:

linha.Quantity = newQuant + 1; //fake, first assign wrong value linha.Quantity = newQuant; // right value

can you repro the error, with some test code with multiple assign/save cycles?

[rubenalves]

There is no triggers involved,

I haved used your solution, create a fake faluem the change to the correct value.

I will let e be like this so that the customers can change and then give me feed back.

Thanks.

[rubenalves]

It happened again, so the only reliable solution is the one i was using before, I have made a Dapper Extention method that saves the value and then i read it again using Vita and it is ok. It probably is a bug in the property chaged event not working as expected, not a problem for me now but it probably is afecting others and they do not know. It probably only happens on aplications that are constantly changing values tht are already loaded for some time.

[rivantsov]

sorry to hear that, I wish I could help, if I had more info - detailed logs when it happens. Hopefully with changes and improvement in the coming refactoring it will be fixed automatically