<beneroth>
abu[m], Regenaxer have you a little time?
<beneroth>
I have a question about 'rel> 'upd> and 'del> methods on entities
<abu[m]>
Hi beneroth! Yes, fine :)
<beneroth>
I have a classic (+Joint) (+List +Joint) relation
<beneroth>
it looks to me, as if:
<beneroth>
1) call 'put> on either relation calls 'rel> and 'upd> on both relations (as expected)
<beneroth>
2) calling 'lose> on the object with the (+Join) rel calls 'del> and 'upd> on the (+List +Joint) relation, but never 'rel> on the (+List +Joint) relation (which I would have expected)
<beneroth>
does this sound plausible? is 'rel> only intended for 'put> call but not the complementary 'del> call?
<abu[m]>
This behavior is intended. +Joints behave asymmetric on lose>
<beneroth>
I haven't set up a simplified test, this seems to be my observance from testing in my application, so I might be mistaken.
<beneroth>
okay
<abu[m]>
The same as (+Ref +Link)
<beneroth>
I see
<abu[m]>
The idea is that the links *from' the losing object are preserved
<beneroth>
though I would say it's not the same (well it behaves the same, I see what you mean) as (+Ref +Link) involves no implicit (put> X 'rel NIL) as +Joint kinda does
<abu[m]>
So that keep> can restore them
<abu[m]>
right
<abu[m]>
if an object gets losts, all references *to* it must be cut off
<beneroth>
I should receive the 'del> call on the other end of the +Joint (on the +List +Joint) right?
<abu[m]>
not those *from* it
<beneroth>
yeah my concerning is the other end of the +Joint, the property value changes there
<abu[m]>
yes
<abu[m]>
The back ref is deleted
<beneroth>
ok. I guess I just add the 'del> implementation then in my additional prefix class than I should be handle that situation too
<beneroth>
I think 'upd> is also not called on the other joint relation, only on the origin one (origin = where the original call/change occured)
<abu[m]>
I'm not sure I got the point: You have A <-> B
<abu[m]>
then (lose> A)
<beneroth>
yes.
<beneroth>
I want to handle the removing of A in the (+List) in B
<abu[m]>
You want also A -> B be cleared?
<beneroth>
no, everything handling with A is okay. I would like to notice that in B a value was removed from the list
<abu[m]>
A should already be cleared in the list in B
<abu[m]>
if A is lost
<beneroth>
yes. it's in the context of (lose> A)
<abu[m]>
yes, then in B it is cleared
<abu[m]>
becauss A should not be referred to any more
<beneroth>
yes, but no 'upd> and no 'rel> is getting called on the +List rel in B
<beneroth>
only 'del> I think
<abu[m]>
ah, yes
<beneroth>
see my point?
<abu[m]>
upd> is on the user level
<beneroth>
well.. 'upd> is on the database level :P
<abu[m]>
Yes, but never called I think
<beneroth>
but yeah.. 'upd> is intended for handling changes to values and 'rel> changes to relation properties.. highly related but not the same. right?
<abu[m]>
reserved for user actions
<abu[m]>
yes, exactly
<beneroth>
ah right.. 'upd> on rel is not called automatically (same as mis>), but 'upd> '+Entity is called automatically I think
<beneroth>
like you use it for +Hist
<abu[m]>
I think there are possible custom functions which can be passed to +Joint
<beneroth>
according to ref +Joint only takes the property arguments to make the +Joint
<beneroth>
I've implemented a custom prefix class on the relation
<beneroth>
with A joint B on the B relation (which is +List +Joint)
<abu[m]>
hmm, seems ref is lacking
<abu[m]>
# (+Joint) var typ [put get]
<beneroth>
ooooooohhhhhh
<abu[m]>
undocumented hack ;)
<abu[m]>
I think I never used it
<beneroth>
and new, pil21? seems not to be present in pil64 implementation
<beneroth>
why did you add it then, if you never used it? :P
<abu[m]>
strange
<abu[m]>
So I needed it recently
<beneroth>
# (+Joint) var typ
<beneroth>
# slot
<beneroth>
(dm T (Var Lst)
<beneroth>
(class +Joint +Link)
<beneroth>
(=: slot (car Lst))
<beneroth>
(super Var (cdr Lst)) )
<beneroth>
pil62 implementation
<beneroth>
yeah
<abu[m]>
right, not in pil64
<beneroth>
well maybe you used it and then your usage got factored out again...but must be rather recently?
<beneroth>
okay
<abu[m]>
I don't remember :(
<beneroth>
no problem, don't worry :)
<abu[m]>
I will search for it
<beneroth>
you helped me already by confirming my understanding :D
<abu[m]>
great :)
<beneroth>
I will switch to pil21 eventually, but will need some time slot where I can do all testing properly :D
<abu[m]>
yeah
<beneroth>
I think I solve it now by additionally implementing 'del> to handle this special situation. maybe I can optimize/simplify it when I switched to pil21
<abu[m]>
And handling it in upd> in A?
<beneroth>
I think +Hist is also affected, as it's implemented on (upd> . +Entity) and in A <-> B joint when doing (lose> A) the B object only ever gets the 'del> on the relation and no (upd> B)
<beneroth>
I like to handle it exclusively in B
<abu[m]>
ok
<abu[m]>
yes, +Hist also does not notice
<beneroth>
I think the upd> in A should not know/depend on the structure in B (besides knowing it must be +Joint of sorts because the rel of B is in the +Joint argument)
<abu[m]>
The link in B is regarded here like a kind of fast index
<beneroth>
yes. which is correct from perspective of A, but in perspective of A it's still a regular value change I would argue
<beneroth>
sorry, second A is meant to be B ofc
<abu[m]>
right, does not care in A (also like an index)
<beneroth>
T
<beneroth>
so I grokked it correctly, thanks for the confirmation and context knowledge :)
<abu[m]>
I search for a +Joint case now in recent projects :)
<beneroth>
and good to know about pil21 having even more goodies in +Joint. I'm keen on switching especially since the input/output update :))
<beneroth>
don't bother spending a lot time searching ;-)
<abu[m]>
yes, and many other improvements
<abu[m]>
no problem, I like to know myself
<beneroth>
I know. Just don't forget lunch :D
<abu[m]>
☺
<abu[m]>
Ha! Found one: (rel amp (+Joint) mes (+Amp) list asoq)
<abu[m]>
@doc/ChangeLog says 'put' and 'get' were added 11jun21
<beneroth>
top
<beneroth>
thank you
calle has joined #picolisp
chexum has quit [Quit: No Ping reply in 180 seconds.]
chexum has joined #picolisp
clacke has joined #picolisp
chexum has quit [Remote host closed the connection]
chexum has joined #picolisp
<abu[m]>
> yes, but no 'upd> and no 'rel> is getting called on the +List rel in B
<abu[m]>
This is indeed worth a discussion. Would you feel that 'upd>' should be invoked on the remote side here? +Dep does so, and it is a similar case.
<beneroth>
I think so. and I'm patching (lose> +Joint) in my application to achieve that effect
<beneroth>
not sure how risky it would be to change the existing code everywhere though
<beneroth>
I agree its same scenario as +Dep
<beneroth>
initially I just wanted to handle 'del> too, but that is the (del> . +relation) where I don't have the Obj
<beneroth>
my use case is basically (not only) +Hist
<beneroth>
<beneroth> initially I just wanted to handle 'del> too, but that is the (del> . +relation) where I don't have the Obj . - the B obj that is
<beneroth>
as you can see in the current/old implementation (also in pil64) the new value calls (put> New (: slot) Obj)
<beneroth>
which in turn calls 'upd>
<abu[m]>
Can you try or test the pil64 version?
<abu[m]>
I see! And not so in pil21?
<abu[m]>
So upd> *is* called in pil64 bubn not in pil21?
<beneroth>
not sure, I don't have pil21 here, but I think there is the same
<beneroth>
no
<beneroth>
'upd> in pil64 is also only called by the (rel> +Joint) when putting/setting a new value
<beneroth>
but... hear this
<beneroth>
maybe it's not +Joint we should change, but (del> . +List)
<beneroth>
hm..no
<abu[m]>
hard to decide the "right" way
<beneroth>
essentially: for the purpose of +Hist and similar custom prefix classes I would like to have the same hook methods/ways to get informed about a new value also when deleting (putting to NIL)
<abu[m]>
I need to trace here to find out more
<beneroth>
adding/setting value is covered, as in all combinations eventually a (put>) gets called which internally calls 'rel> and 'upd> etc.
<abu[m]>
yes, but upd> is not only for +Hist, and more critical in other situations
<beneroth>
also when that 'put> is triggered on the B object because it was used in put> on A
<beneroth>
T
<abu[m]>
I use it to trigger various tasks
<beneroth>
yep, same :D
<abu[m]>
In my view until now, the joint backlink is "automatism" while the +Dep side effects are "user"
<beneroth>
the complementary situation of +Joint-triggered removal of A-object from B property (list) does not give a 'rel> or 'upd> on B or B relations
<beneroth>
my current use case is: some properties have effects on other properties, e.g. changing a date updates another date at another object. because those dates must be kept in sync but still be separate for special cases when they are not to be kept in sync
<abu[m]>
yes, typical case
<beneroth>
now one of the triggering relations for such a custom application trigger happens to be +List +Joint :)
<beneroth>
but when the +Joint is changed (by user) from the other end (at A), then I don't get the trigger for the application updates on the B object
<abu[m]>
so it should be handled on the user side, not the auto side
<abu[m]>
I think we can get into infinite dependencies otherwise
<beneroth>
a point to argue about
<abu[m]>
yeah
<beneroth>
my data changes don't come only from GUI / users but also from periodic imports
<abu[m]>
+Dep is a border case
<abu[m]>
yes, input should not matter
<beneroth>
yes we can get infinite dependencies and the custom trigger bust have safety checks for that
<beneroth>
so yes, ideally I want it work like +Dep directly on the pilDB level, not another layer on top of it.
<abu[m]>
GUI is usually not a problem, cause the GUI fields can do anything with +Chg etc
<beneroth>
simplest and the least amount of code
<beneroth>
T
<beneroth>
another layer on top of pilDb, so has more options, has more context to work with, but also requires more context/bookkeeping
<abu[m]>
right
<beneroth>
that would be the other approach, doing my stuff here not in pilDB layer, but one layer above which then would be used by GUI and by imports
<beneroth>
but directly in pilDB is much easier, also to have cascading effects without having to know about the cascade. except the risk for infinity :)
<beneroth>
(circular triggers)
<abu[m]>
I wonder why I put upd> into +Dep
<abu[m]>
whether it was really needed
<beneroth>
in certain sense, maybe (del> +List) is the culprit, not +Joint. The (del> +List) does no 'rel> 'upd> calls. Then again the positive case of putting on a +List relation is also not handled in +List but only the base relation classes
<abu[m]>
I would not touch +List here
<abu[m]>
And del> is not used outside of @lib/db.l anyway
<beneroth>
so maybe handling 'del> on base relation classes and make it issue 'upd> calls would be the consequent thing.
<beneroth>
T
<abu[m]>
(or do you call 'del>"?)
<beneroth>
I don't think so, but I cannot fully guarantee without searching my apps. maybe I use (del>) to remove single entries from +List relations. often I (put>) the new list, I believe
<abu[m]>
It is extremely dangerous to change +List I think
<beneroth>
T
<beneroth>
how dangerous is changing (lose> '+Joint) you think?
<beneroth>
that's the way I'm testing right now
<beneroth>
looks good to me
<abu[m]>
lose> never calls upd>
<beneroth>
no, but usually it does not issue a 'put> on another object which 'lose> +Joint conceptually does
<beneroth>
well it does it via 'del>
<beneroth>
so maybe better stuff it into (del> . +Joint) instead, you think?
<beneroth>
it's in general somewhat ugly, I know :D
<abu[m]>
Better not intoduce more side effects.I rather wonder whether upd> should be removed from +Dep
<abu[m]>
+Dep was always a kind of second-thought
<beneroth>
well I need a trigger to handle every change in a (+List +Joint) relation
<beneroth>
yeah I can see that
<abu[m]>
It is not really needed
<beneroth>
well.. it's nice to have it in one place instead having to have the same effect implemented multiple times
<abu[m]>
So the +List is only your current case
<abu[m]>
a single Joint has the same situation
<beneroth>
(rel> . +Dep) calls 'put>, therefore the 'upd> and 'rel> calls are triggered
<beneroth>
true
<abu[m]>
not being upd>ed
<beneroth>
for the needs of +Hist there I have the same issue
<abu[m]>
I understand +Hist to record user actions
<beneroth>
I think it's a shortcoming that +Hist is not logging changes of (+Joint) to NIL, as (put> Obj 'rel NIL) (or (put> Obj 'rel) if you prefer) is handled in +Hist
<abu[m]>
So auto effects are not logged
<beneroth>
they are, when they are going through put>
<beneroth>
which they are in +Dep and +Joint
<beneroth>
for non-NIL cases
<beneroth>
well +Dep explicitely calls 'put> with NIL value
<abu[m]>
I haven't checked +Hist for a long time. Could be more intelligent anyway
<beneroth>
but the +Joint removels/NIL-settings are missed
<abu[m]>
only on the remote side, right?
<beneroth>
yes
<abu[m]>
so it is consistent
<beneroth>
in some sense. but the +Hist trail is missing some parts for the remote side.
<abu[m]>
In case of your Joint issue, the put and get functions would help
<abu[m]>
nobody changed the remote side
<beneroth>
e.g. if you use +Hist to later find all modifications to a certain record, the modifications done by indirect +Joint stuff (where the record was the remote side) is not tracked
<abu[m]>
The user changed locally, and can see what he did
<abu[m]>
ok, then you need deeper logging
<abu[m]>
Hist is to find out who destroyed the data
<beneroth>
I log using something very similar to your +Hist
<beneroth>
<abu[m]> Hist is to find out who destroyed the data
<beneroth>
yep
<beneroth>
well also any data changes in my case
<abu[m]>
yeah, no destroy usually
<abu[m]>
But put and get for Joint can solve your problem?
<abu[m]>
Passing functions which return the objectt but do some side effects?
<beneroth>
for the automations.. yes, probably the most elegant way.
<beneroth>
better than prefix class
<abu[m]>
T
<beneroth>
though I need the same mechanism for non-+Joint relations, so there it still would be a prefix class
<beneroth>
maybe doing a prefix class to give put/get to any type of relation
<abu[m]>
prefix to relation
<beneroth>
T
<beneroth>
not Entity as with +Hist
<beneroth>
another topic
<abu[m]>
yes, this sounds best to me
<beneroth>
yes agreed. lets not change +Joint in pil21
<abu[m]>
ok :)
<beneroth>
I solve it now with my somewhat ugly patching of (lose> . +Joint) because I don't have put/get in pil21
<beneroth>
eh pil64
<abu[m]>
And we also keep +Dep as it is
<beneroth>
this topic considered solved, thank you, agreed
<beneroth>
yes I think so
<beneroth>
no pressing need to change it, just gives headaches
<beneroth>
evenw hen +Dep is for very specific rare use anyway
<abu[m]>
Thanks for this important discussion!
<beneroth>
I thank you!
<abu[m]>
also more clear for me now
<beneroth>
what about +Hist not receiving +Joint side effects? :P
<beneroth>
arguably it's a relation update when a remote side gets changed
<abu[m]>
+Hist is completely free anyway (not part of the distro iirc)
<beneroth>
the positive situation (adding/setting a new value) is handled, but not removal
<beneroth>
T
<beneroth>
good point :)
<beneroth>
it's a custom thingy, so if people need it, they can customize other stuff to, no warranty given :)
<beneroth>
<beneroth> the positive situation (adding/setting a new value) is handled, but not removal
<beneroth>
still I find this somewhat inconsistent
<abu[m]>
In my versions (all similar) all is done in upd>
<abu[m]>
So NIL settings could be handled
<beneroth>
yeah, so you are tracking (put> Obj 'rel NIL) but not when triggered by remote +Joint
<abu[m]>
ok, yes
<abu[m]>
There is (let (Rel (meta This X)
<beneroth>
my version is also only using the (upd> . +Entity) (+Hist is on entity, not relation).
<abu[m]>
T
<beneroth>
analysing its arguments to decide what change is made (class change, property set, or lose> or keep>)
<abu[m]>
But when 'Rel' is a +Joint ...
<beneroth>
everything is there.. except for changes to NILs which never went through a put> (as in del> and remote +Joint)
<beneroth>
for the non-remote side, the +Joint never matters, as for the udp> mechanism it's just a normal value change
<abu[m]>
Where did you get your +Hist from?
<beneroth>
which goes through 'put> at some point
<beneroth>
what do you mean?
<beneroth>
you sent me once a version of you. and I used it to learn the workings and implemented my own.
<abu[m]>
I have several versions in several projects
<beneroth>
my version is definitively different than yours, but same concepts
<beneroth>
I put logs into the database
<beneroth>
they have their own database files
<abu[m]>
yes, I see that mine are all similar
<abu[m]>
(I find 11 er.l files with a +Hist)
<beneroth>
:)
<beneroth>
I have one file which is loaded in multiple projects :)
<abu[m]>
all very similar, I did not much to improve
<abu[m]>
☺
<beneroth>
but yeah, thats one of the main differences in our approaches, I share code between projects, you don't outside of pil distro (copy paste is different)
<abu[m]>
+Hist is ony differing in printing the entities in user-readable texts
<beneroth>
both approoaches have their merits and benefits.
<beneroth>
ah okay
<beneroth>
so logic is the same :)
<beneroth>
and I guess you don't handle all changes (e.g. class changes with set> ?)
<beneroth>
not needed usually, I would assume?
<abu[m]>
yes, I have a skel/directory to fork a new project
<beneroth>
allows more customizations without dependencies on other stuff
<abu[m]>
Class changes are set> in the +ClassField usually
<abu[m]>
and seldom call 'set>' explicitly
<beneroth>
point is, also in your logs, there will be no entries for changes on the remote end of +Joint, but ofc you have the origin side of the +Joint in the log
<beneroth>
that would be another way, instead of ensuring 'upd> being called for remote changes too, I could during writing of logs check if the relation is a joint and if so create a log for the remote end too...
<abu[m]>
yes
<beneroth>
I need to think about this, might be the better approach, but I'm not sure yet.
<abu[m]>
In fact my users use the +Hist records much more often than me
<abu[m]>
I never looked much :(
<beneroth>
regarding class changes: i used it in the past very successfully to represent phases/states of a process some data goes through. for every phase/status there is some data which is alway same and some which changes, and it's useful to have different indexes. so I have different entities for the different phases, inheriting from a base entity which defines everything which is shared by all of them (also shared index)
<beneroth>
that worked out very elegantly. that application is still in use. and I think I will use this approach again.
<abu[m]>
Sounds very good
<beneroth>
easy to use in pilDB. doing that with an SQL database would mean a lot of duplicated code.
<abu[m]>
I also usually have different idexes or relations, which are updated via 'set>'
<beneroth>
and also allowed to add additional phases in between, also optional ones.
<beneroth>
yeah
<beneroth>
set> is very elegant
<beneroth>
and well the underlying non-DB OOP is very nice
<beneroth>
thats an re-occuring issue / reason for a lot of duplicate code and bloat in C# and Java, they copy properties from one object to another
<beneroth>
as they cannot change the class of an object
<beneroth>
same even with C++
<abu[m]>
very short-sighted design ;)
<abu[m]>
well, not easy in a static system
<abu[m]>
The compiler needs exact object sizes
<abu[m]>
ok, we have supper it seems ☺
<abu[m]>
Let's keep an eye on these things
<beneroth>
boils down to the memory management. the random cell allocation makes it possible (for a cost in general overhead in both fragmentation and performance), while in C++/java/C# the memory is in fix blocks but if the block doesn't fit anymore you have to reallocate verything
<beneroth>
mahlzeit :)
<abu[m]>
T - And Danke! ☺
<beneroth>
for application software I find the pil design more useful :)
<beneroth>
Danke an Dich! Grüsse!
<abu[m]>
☺
tankf33der has quit [*.net *.split]
clacke has quit [*.net *.split]
casaca has quit [*.net *.split]
abu[m] has quit [*.net *.split]
beneroth has quit [*.net *.split]
Regenaxer has quit [*.net *.split]
stux has quit [*.net *.split]
f8l has quit [*.net *.split]
Nistur has quit [*.net *.split]
genpaku has quit [*.net *.split]
Hunar has quit [*.net *.split]
calle has quit [*.net *.split]
mario-goulart has quit [*.net *.split]
viaken has quit [*.net *.split]
TeddyDD has quit [*.net *.split]
payphone has quit [*.net *.split]
Iacob has quit [*.net *.split]
chexum has quit [*.net *.split]
chexum has joined #picolisp
clacke has joined #picolisp
calle has joined #picolisp
beneroth has joined #picolisp
genpaku has joined #picolisp
Regenaxer has joined #picolisp
mario-goulart has joined #picolisp
abu[m] has joined #picolisp
Hunar has joined #picolisp
casaca has joined #picolisp
tankf33der has joined #picolisp
payphone has joined #picolisp
stux has joined #picolisp
f8l has joined #picolisp
viaken has joined #picolisp
Nistur has joined #picolisp
TeddyDD has joined #picolisp
Iacob has joined #picolisp
chexum has quit [Quit: No Ping reply in 180 seconds.]
chexum has joined #picolisp
chexum has quit [Remote host closed the connection]
chexum has joined #picolisp
chexum has quit [Remote host closed the connection]
chexum has joined #picolisp
chexum has quit [Remote host closed the connection]
chexum has joined #picolisp
clacke has quit [Read error: Connection reset by peer]
calle has quit [Ping timeout: 268 seconds]
theruran has quit [Quit: Connection closed for inactivity]
Regenaxer has quit [Remote host closed the connection]
chexum has quit [Quit: No Ping reply in 180 seconds.]