JSON-B: can PropertyVisibilityStrategy be non-caching? - jsonb

I note that the following code...
JsonbBuilder.create( new JsonbConfig()
.withPropertyVisibilityStrategy( mRoleBasedPropertyVisibilityStrategy )
...creates a Jsonb instance whose PropertyVisibilityStrategy only gets called once per class. Subsequent calls appear to cache the visibility of each property.
This makes it inappropriate for something like a mRoleBasedPropertyVisibilityStrategy, which needs to check the visibility each time based on a given logged-in user's role.
Is there a way to force PropertyVisibilityStrategy not to cache?

Related

How exactly does the fetchAllIfNeeded differ from fetchAll in the JS SDK?

I never quite understood the if needed part of the description.
.fetchAll()
Fetches the given list of Parse.Object.
.fetchAllIfNeeded()
Fetches the given list of Parse.Object if needed.
What is the situation where I might use this and what exactly determines the need? I feel like it's something super elementary but I haven't been able to find a satisfactory and clear definition.
In the example in the API, I notice that the fetchAllIfNeeded() has:
// Objects were fetched and updated.
In the success while the fetchAll only has:
// All the objects were fetched.
So does the fetchAllIfNeeded() also save stuff too? Very confused here.
UPDATES
TEST 1
Going on some of the hints #danh left in the comments I tried the following things.
var todos = [];
var x = new Todo({content:'Test A'}); // Parse.Object
todos.push(x);
x.save();
// So now we have a todo saved to parse and x has an id. Async assumed.
x.set({content:'Test B'});
Parse.Object.fetchAllIfNeeded(todos);
So in this scenario, my client x is different than the server. But the x.hasChanged() is false since we used the set function and the change event is triggered. fetchAllIfNeeded returns no results. So it isn't that it's trying to compare this outright to what is on the server to sync and fetch.
I notice that in the request payload, running the fetchAllIfNeeded is sending the following interesting thing.
{where: {objectId: {$in: []}}, _method: "GET",…}
So it seems that on the clientside something determines whether an object isNeeded
Test 2
So now, based on the comments I tried manipulating the changed state of the object by setting with silent.
x.set({content:'Test C'}, {silent:true});
x.hasChanged(); // true
Parse.Object.fetchAllIfNeeded(todos);
Still nothing interesting. Clearly the server state ("Test A") is different than clientside ("Test C"). and I still results [] and the request payload is:
{where: {objectId: {$in: []}}, _method: "GET",…}
UPDATE 2
Figured it out by looking at the Parse source. See answer.
After many manipulations, then taking a look at the source - I figured this out. Basically fetchAllIfNeeded will fetch models in an array that have no data, meaning there are no attribute properties and values.
So the use case would be you have lets say a parent object with an array of nested Parse Objects. When you fetch the parent object, the nested child objects in the array will not be included (unless you have the include query constraint set). Instead, the pointers are sent back to clientside and in your client, those pointers are translated into 'empty' models with no data, basically just blank Parse.Objects with ids.
Specifically, the Parse.Object has an internal Boolean property called _hasData which seems to be toggled true any time stuff like set, or fetch, or whatever gives that model attributes.
So, lets say you need to fetch those child objects. You can just do something like
var childObjects = parent.get('children'); // Array
Parse.Object.fetchAllIfNeeded(childObjects);
And it will search for those children who are currently only represented as empty Objects with id.
It's useful as opposed to fetchAll in that you might go through the children array and lazily load one at a time as needed, then at a later time need to "get the rest". fetchAllIfNeeded essentially just filters "the rest" and sends a whereIn query that limits fetching to those child objects that have no data.
In the Parse documentation, they have a comment in the callback response to fetchAllIfNeeded as:
// Objects were fetched and UPDATED.
I think they mean the clientside objects were updated. fetchAllIfNeeded is definitely sending GET calls so I doubt anything updates on the serverside. So this isn't some sync function. This really confused me as I instantly thought of serverside updating when they really mean:
// Client objects were fetched and updated.

Public Read and Write ACL despite all permissions being disabled

I have a class with all the permissions disabled, so it's available only to my cloud code while using the master key. But I looked at it today and I'm seeing that suddenly each of my objects has a Public Read and Write ACL.
What does it mean? I do not want anyone writing to, or reading from this class. Do I have to now set this in two different places?
I should add that this class contains information that I've added myself through the data browser. No app is writing to it.
I also found this a bit confusing and here's what I think is happening:
There appears to be the same notion of undefined for ACL's as for other cells. I think that is the default security ACL (non) value. However, when the ACL is undefined, it gets reported in the Data table viewer, under the ACL column, as "Public Read and Write". I suspect that someone at Parse decided that showing (undefined) for the ACL wouldn't do justice to informing the developers of the security risk of having no ACL for the row.
As evidence of what I'm thinking, I have noticed that when you click on an ACL cell (as if to edit), and it brings up the security dialog box for the ACL of the row, then, in the original cell itself (where you clicked, now in the background), it shows the text (in JSON) of the old ACL, if there is one actually defined, and shows (undefined) if there isn't one defined yet.
My observation is that class-specified security overrides what I'm calling the undefined ACL security setting.
IMHO, it would be better in this case if the Data view page showed something more illustrative: instead of "Public Read and Write", for example, "(undefined: see class security...).
Also, it is not yet clear to me how class security combines with row-defined ACLs (i.e. when present). If I find out one way or the other, I'll update...
(Also, fyi, sometimes it seems to me that you may have to give a few minutes before seeing security setting changes take effect.)

Peoplesoft Peoplecode events

i am new to Peoplesoft software and the PeopleCode programming. I have been doing alot of exercises with PeopleCode. I have a question whereby the record fields events such as FieldDefault and etc etc....
I have made an application whereby user can search and add new value. So in a case where I have Peoplecode in one of the event for example SaveEdit, when I click the save button in both cases of search data or adding new value tab, it points to the same PeopleCode.
Is there any method whereby the code will know when user are searching existing data or adding value or rows in PeopleSoft?
Wont it be conflicting for both cases to point to the same PeopleCode?
Another question:
Hi i have a question regarding the passing of variables between the FieldFormula event and SavePostChange.
I have some values being calculated in the FieldFormula and I want to access it in SavePostChange event as I want to prompt messagebox based on the value being calculated.
I have been using the Global variables to access the variables.
Is there any good way to pass the variables or access to the variables values?
In the case of search records, there are a couple of Search-specific events, SearchInit and SearchSave. SaveEdit is when the record is saving so it shouldn't have a conflict with Searchevents.
Additionally you can place code either in the Record PeopleCode (fires every time someone uses that Record in a Component) or in Component Record PeopleCode (just that component). Record PeopleCode fires first then Component Record PeopleCode. The Component PeopleCode also has additional events that the record level ones don't, like SavePreChange and SavePostChange. So once you get the hang who fires when you can get pretty granular control of the various events.
There is actually a pretty good summary in the PeopleBooks here.
Regarding your question of how to differentiate between adding a new value and working on existing one, I would suggest you to use %Mode variable in peoplecode.
When working on existing value %Mode takes the value as "U" ie Update Mode
If %Mode="U" then
/**YOUR CODE**/
End-if;
When working on New value %Mode takes the value as "A" ie Add Mode
If %Mode="A" then
/**YOUR CODE**/
End-if;

User has_many posts. Get all users that have at least 1 post

Users have_many posts.
In a view, I want to get an alphabetized list of all users that have at least 1 post. Here is how I currently do it. Is there a way to make this all one line / using better Rails ActiveRecord conventions?
#users.order("name ASC").each do |user|
if user.posts > 0
...
end
end
Your current solution isn't bad (it's a single query) but it can be improved.
You can use ActiveRecord's built-in counter cache functionality to store the number of associated objects on the parent (in this case, the number of posts associated with a user). Then you can craft a query like this:
User.where('posts_count > 0').order('name ASC')
Here are the docs on :counter_cache (taken from here):
:counter_cache
Caches the number of belonging objects on the associate class through the use of increment_counter and decrement_counter. The counter cache is incremented when an object of this class is created and decremented when it's destroyed. This requires that a column named #{table_name}_count (such as comments_count for a belonging Comment class) is used on the associate class (such as a Post class) - that is the migration for #{table_name}_count is created on the associate class (such that Post.comments_count will return the count cached, see note below). You can also specify a custom counter cache column by providing a column name instead of a true/false value to this option (e.g., counter_cache: :my_custom_counter.) Note: Specifying a counter cache will add it to that model's list of readonly attributes using attr_readonly.
We can get all the user ids which have atleast one post using this.
Post.uniq.pluck(:user_id);
And then we can fetch all the user as follows.
User.order(:name).find(Post.uniq.pluck(:user_id));
User.joins(:posts).order('users.name asc') will perform an inner join, as described in the documentation here. A counter cache isn't a bad solution either.

What is the best practice for disabling a cache request from the Full Page Cache (FPC) in magento (enterprise)

I wish to remove the following setting:
<cms>enterprise_pagecache/processor_default</cms>
... from the config.xml of the core / Enterprise / PageCache / config.xml file so that the home page will not be cached, (because we have a complicated custom store switch in place).
Since this value is not stored in core_config_data I am unsure of the best way to override the out of the box value. The comments above the line in the core file do hint that it is not actually bad practice to edit this file, however, can I open this to the community to see what they think?
PS = This is a multi website setup with a custom store switcher.
Hole punching is what it sounds like you may need.
Add a etc/cache.xml file with a <config> root to your module. (see Enterprise/PageCache/etc/cache.xml). Choose a unique [placeholder] name.
The placeholders/[placeholder]/block node value must match the class-id of your custom dynamic block, e.g. mymodule/custom
The placeholders/[placeholder]/container node value is the class to generate the content dynamically and handle block level caching
The placeholders/[placeholder]/placeholder node value is a unique string to mark the dynamic parts in the cached page
placeholders/[placeholder]/cache_lifetime is ignored, specify a block cache lifetime in the container’s _saveCache() method if needed
Implement the container class and extends Enterprise_PageCache_Model_Container_Abstract. Use _renderBlock() to return the dynamic content.
Implement the _getCacheId() method in the container to enable the block level caching. Use cookie values instead of model ids (lower cost).
One last note: You DON’T have the full Magento App at your disposal when _renderBlock() is called. Be as conservative as possible.
SOURCE: http://tweetorials.tumblr.com/post/10160075026/ee-full-page-cache-hole-punching

Resources