Vreman, Peter - Acision wrote:
I want to store a temporary object in a collection. The temporary
object does not need to be serialized to the disk. When I create the
object and call the save_xxxx function with save=False the object is
stored in the list. But there is something in collection.add() with
_/internal/_cache_update that is only called when Save=True.
Internal cache update is a misnomer. What it actually does is make sure
that a non-cobblerd API handle, when it changes an object, signals
cobblerd that it needs to reload the configuration of that object (or
otherwise remove it from the list)
Some questions about caches and values:
- Are the internal_caches still required?
The function should be renamed, "notify_cobblerd" or equivalent.
- Why is the internal_cache only updated when the data is serialized
to disk?
There's no cache anymore ... well, not COMPLETELY true. New object
handles BEFORE they are saved to disk with edits applied, are kept in
RAM. This is "object_cache" in cobblerd and does not have
any bearing with the "notify_cobblerd" feature that is named
"internal_cache_update" (from when there really was a cache). I just
ripped the cache out in 1.6 since things were so fast we didn't need it.
- What does the to_datastruct_with_cache() provide in addition or is a
replacement?
This is a theoretical speedup, an internalism, that I really need to
benchmark to prove it adds value. The idea was to prevent running
to_datastruct() if the object reference already knew what the result was
because the object hasn't changed after the last time we ran it.
- Why does remote __get_specific use the raw serializer and not the
objects from memory?
Partially paranoia. It ensures we get the very latest that has been
serialized to disk even if notification from the API handle failed or
someone did an edit to the file on the disk that happened outside the
API -- note we don't do any inotify watching of the files in question to
see if changes happen outside of our knowledge.
The more realistic answer is that it's a vestige of the way things used
to work.
We probably don't need to and would suffer no adverse effects from just
grabbing the object.
===
Anyway, bottom line, if you want to implement saved searches, this
/might/ not be the best way. We don't want to introduce a new class
of cobbler "nouns" because nouns are kind of heavy.
I like the idea of bookmarking searches namely because it's light weight
and subscribes to Larry Wall's definition of laziness very nicely.
We could implement a function to list and save a search, kind of in it's
own remote.py specific way, I suppose -- but I don't think if we did
that it should be a first class Cobbler object. Ultimately I am not
sure if the complexity of doing either would be worth it -- though I
understand where you are coming from a bit.
Another way to do it might be to just have a user editable template that
would hold the search URLs ... which is kind of what we have. Perhaps
a way to put the saved searches in settings and make them show up on the
WebUI automatically?
Regards,
Peter
This e-mail and any attachment is for authorised use by the intended
recipient(s) only. It may contain proprietary material, confidential
information and/or be subject to legal privilege. It should not be
copied, disclosed to, retained or used by, any other party. If you are
not an intended recipient then please promptly delete this e-mail and
any attachment and all copies and inform the sender. Thank you.
------------------------------------------------------------------------
_______________________________________________
cobbler-devel mailing list
cobbler-devel(a)lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/cobbler-devel