I'm trying to understand a basic use case of working with GAE db.ReferenceProperties.
Example:
A Magazine db.Model entity has a db.ReferenceProperty(Publisher). I want to get a list of 10 Magazines to display in a table, that has a publisher column populated by model.publisher.name. Am I making 11 queries- one for the Magazine list result, and another one each everytime I reference the .publisher property?
The reference property isn't doing queries - it's doing datastore gets, which are faster - but you're correct that it does one per reference you resolve. You can batch them up using this pattern.
Related
I'm managing a company website, where we have to display our products. We however do not want to handle the admin edit for this CPT, nor offer the ability to access to the form. But we have to read some product data form the admin edit page. All has to be created or updated via our CRM platform automatically.
For this matter, I already setup a CPT (wprc_pr) and registered 6 custom hierarchical terms: 1 generic for the types (wprc_pr_type) and 5 targeting each types available: wprc_pr_rb, wprc_pr_sp, wprc_pr_pe, wprc_pr_ce and wprc_pr_pr. All those taxonomies are required for filtering purposes (was the old way of working, maybe not the best, opened to suggestions here). We happen to come out with archive pages links looking like site.tld/generic/specific-parent/specific-child/ which is what is desired here.
I have a internal tool, nodeJS based, to batch create products from our CRM. The job is simple: get all products not yet pushed to the website, format a new post, push it to the WP REST API, wait for response, updated CRM data in consequence, and proceed to next product. Handle about 1600 products today on trialn each gone fine
The issue for now is that in order for me to put the correct terms to the new post, I have to compute for each product the generic type and specific type children.
I handled that by creating 6 files, one for each taxonomy. Each file is basically a giant JS object with the id from the CRM as a key, and the term id as a value. My script handles the category assertion like that:
wp_taxonomy = [jsTaxonomyMapper[crm_id1][crm_id2]] // or [] if not found
I have to say it is working pretty well, and that I could stop here. But I will have to take that computing to the wp_after_insert_post hook, in order to reaffect the post to the desired category on updated if something changed on the CRM.
Not quite difficult, but if I happen to add category on the CRM, I'll have to manually edit my mappers to add the new terms, and believe me that's a hassle.
Not waiting for a full solution here, but a way to work the thing. Maybe a way to computed those mappers and store their values in the options table maybe, or have a mapper class, I don't know at all.
Additional information:
Data from the CRM comes as integers (ids corresponding to a label) and the mappers today consist of 6 arrays (nested or not), about 600 total entries.
If you have something for me, or even suggestions to simplify the process, I'll go with it.
Thanks.
EDIT :
Went with another approach, see comment below.
I have an Authors App which has x amount of authors. I have another app and have configured an Field Input-Type entity-query in it which pulls from the Authors App. It does this correctly and I can select multiple authors. However upon save, when I go to retrieve a content item which should contain the selected authors, I am given "empty slot" for the place of each author
Real entity fields are Entity relations, and they enforce validity. So they only work with entities in the same app, as that's kind of a sealed scope. This is important that Apps can ensure export/import and still work for all standard use cases.
To reference entities of another app you must use strings instead. This can be done using the string-query field which has the same functionality.
The only downside is that your code will need to then look up the entity in the other app using the id or guid (whichever you store) in Razor.
I am looking to create a feature whereby a User can download any available documents related to the item from a tab on the PDP.
So far I have created a custom record called Documentation (customrecord_documentation) containing the following fields:
Related item : custrecord_documentation_related_item
Type : custrecord_documentation_type
Document : custrecord_documentation_document
Description : custrecord_documentation_description
Related Item ID : custrecord_documentation_related_item_id
The functionality works fine on the backend of NetSuite where I can assign documents to an Inventory item. The stumbling block is trying to fetch the data to the front end of the SCA webstore.
Any help on the above would be much appreciated.
I've come at this a number of ways.
One way is to create a Suitelet that returns JSON of the document names and urls. The urls can be the real Netsuite urls or they can be the urls of your suitelet where you set up the suitelet to return the doc when accessed with action=doc&id=_docid_ query params.
Add a target <div id="relatedDocs"></div> to the item_details.tpl
In your ItemDetailsView's init_Plugins add
$.getJSON('app/site/hosting/scriptlet.nl...?action=availabledoc').
then(function(data){
var asHtml = format(data); //however you like
$("#relatedDocs").html(asHtml);
});
You can also go the whole module route. If you created a third party module DocsView then you would add DocsView as a child view to ItemDetailsView.
That's a little more involved so try the option above first to see if it fits your needs. The nice thing is you can just about ignore Backbone with this approach. You can make this a little more portable by using a service.ss instead of the suitelet. You can create your own ssp app for the function so you don't have to deal with SCAs url structure.
It's been a while, but you should be able to access the JSON data from within the related Backbone View class. From there, within the return context, output the value you're wanting to the PDP. Hopefully you're extending the original class and not overwriting / altering the core code :P.
The model associated with the PDP should hold all the JSON data you're looking for. Model.get('...') sort of syntax.
I'd recommend against Suitelets for this, as that's extra execution time, and is a bit slower.
I'm sure you know, but you need to set the documents to be available as public as well.
Hope this helps, thanks.
For example I have a wpf window bound to an customer Entity (let suppose it's cus1). Then I load another entity from context :
customer cus2 = context.customers.where(x=>x.id=10).FirstOrDefault();
Now I want cus1 = cus2 ? I can do this way :
cus1.name = cus2.name;
cus1.address = cus2.address;
...
...
This way meets my case (the content of textboxs in the form change immediately into values of cus2) but I wonder if there is anyway to make it shorter since cus1=cus2 doesn't work ?
Thanks
You can use the memberwise Clone method to make a shallowcopy of a business object:
See http://msdn.microsoft.com/de-de/library/system.object.memberwiseclone.aspx
You could also use Serialization or Reflection, to do it on your own. However both oof the methods are slower then writing it directly.
Take a look at this article. Maybe you will find it helpful:
http://www.codeproject.com/KB/dotnet/CloningLINQ2Entities.aspx
Edit:
Btw. Remember, using using MemberwiseClone, in case of ReferenceTypes will effect in copying the references, not objects.
If you want to update the values of a Customer entity in memory with the newest values in the datastore you can use the Refresh method on your ObjectContext.
Here is the documentation.
In your case it would look like:
context.Refresh(RefreshMode.StoreWins, cus1);
If you really want to map two entities you could have a look at AutoMapper. AutoMapper will help you by automatically mapping entities to each other with a default setup that you can tweak to your needs.
I can't seem to do this. The list that the app engine datastore viewer does not contain Text as an option. I had to change my fields because some of my values were too long for String, but now I can't retroactively fix my old entries.
To change the property type used by the old entities, you need to manually update each of them.
This can be easily and efficiently accomplished using the mapper API. This guide explains how to use this API.
You may also want to read this blog post by Nick Johnson.
You don't have to fix your old entries. The old ones should work as is, and the new ones just won't be indexed.
See
http://groups.google.com/group/google-appengine/browse_thread/thread/282dc825f9c46684 .