How do I set the Transaction Code (TCODE) in a JCO program and then fetch the required function?
e.g. if I need to access SE11 or SE13 related function?
Is the TCODE setting really important?
JCO programs call RFC-enabled module function. A Transaction code is not associated with such a function (se93 will show you the type of object that can be associated with any TCode).
se11 allows to display (and modify) the structure of a table/view/structure. How do you want a RFC call on a distant server to interact with that ?
Related
I am trying out the ts-morph npm module to replace some code which I have already written but which overlaps ts-morph and is inferior. Nevertheless, I have some existing functions that take an ts.Node type arguments, mostly for exploration and discovery, which I need to use for reference while trying out ts-morph.
However, I can't see a way to access the underlying ts.Node instance from a ts-morph.SourceFile instance - there are no ts-morph functions with return type of ts.Node or ts.TypeChecker.
This doesn't work
(sourceFile as unknown) as ts.SourceFile,
(checker as unknown) as ts.TypeChecker,
because, for starters, (sourceFile as unknown) as ts.SourceFile doesn't have a kind member.
Is there a way access the underlying ts.Node instance from, e.g., ts-morph.SourceFile?
ts-morph provides access to all the underlying compiler API objects it wraps.
For any node, you can access the underlying compiler node using the compilerNode property:
sourceFile.compilerNode // ts.SourceFile
Note though that the underlying compiler node will become out of date whenever the source file is manipulated via ts-morph (ex. you add a class to the source file, remove a function, or other stuff like that).
https://github.com/dsherret/ts-morph/blob/af35677f3b498ed0f8e87e4b6c92a7246cfab210/packages/ts-morph/lib/ts-morph.d.ts#L3189
To get the TypeScript TypeChecker, use the compilerObject property on TypeChecker:
project.getTypeChecker().compilerObject // ts.TypeChecker
We want to remove elements from Map bin based on size. There will be multiple threads which will try to do above operation. So writing an UDF to do this operation will make it synchronized between threads. But remove_by_rank_range is not working inside lua. Below is the error iwe are getting:
attempt to call field 'remove_by_rank_range' (a nil value)
sample lua code:
function delete(rec)
local testBinMap = rec.testBin
map.remove_by_rank_range(testBinMap, 0, 5)
end
The Lua map API does not include most of the operations of the Map data type, as implemented in the clients (for example, the Java client's MapOperation class).
The performance of the native map operations is significantly higher, so why would you use a UDF here, instead of calling remove_by_rank_range from the client?
The next thing to be aware of is that any write operation, whether it's a UDF or a client calling the map remove_by_rank_range method, first grabs a lock on the record. I answered another stackoverflow question about this request flow. Your UDF doesn't give any advantage to the problem you described over the client map operation.
If you want to cap the size of your map you should be doing it at the very same time you're adding new elements to the map. The two operations would be wrapped together with operate() - an insert, followed by the remove. I have an example of how to do this in rbotzer/aerospike-cdt-examples.
I have a PlayerPref that spawn more objects in OnStartLocalPlayer().
So in OnStartLocalPlayer() it call Command(assume that called on server) that instantiate GameObject and setup some values of its scripts. At the end it calls SpanWithClientAuthority()...
The thing is that on owner client and on server those script tweeks are correct, but on all other clients it lost all that settings(ex. gameobject ref etc). What do I do wrong?
Once more in nutshell: playerPref GO must have ref list of several other objects, and those objects must have ref to that playerPref GO. (making them part of playerPref GO is not a solution).
If I understand your problem correctly, you need the references to be set across all clients who have the same game object. [Command]'s are for client to server. What you need is a [ClientRpc]. Make the OnStartLocalPlayer() call a [ClientRpc] function, in that function (ex: RpcSetRefs()) set the references you need each client to have.
I just created one c program to create threads using POSIX thread library functions.I didn't use pthread_attr_init() function in that. Even my program works fine.So, what is the use of pthread_attr_init() and what does it do...? I am not familiar in thread concepts.Can anyone tell me is it compulsory to use pthread_attr_init() in thread concept program..?
pthread_attr_init is used to initialise a thread attributes structure, which can then be passed to pthread_create.
If you are creating threads with default attributes, you pass a NULL pointer for the thread attributes argument to pthread_init and there is no need to initialise an attribute structure.
However, if you want to configure specific thread attributes, such as scheduling policy, priority, concurrency level, then you must use pthread_attr_init to initialise the attribute structure before manipulating it using the attribute accessors functions (pthread_set... and pthread_get...) and passing it to the pthread_init function.
I'm trying to understand when I should call Query.close(Object) or Query.closeAll();
From the docs I see that it will "close a query result" and "release all resources associated with it," but what does "close" mean? Does it mean I can't use objects that I get out of a Query after I've called close on them?
I ask because I'm trying to compartmentalize my code with functions like getUser(id), which will create a Query, fetch the User, and destroy the query. If I have to keep the Query around just to access the User, then I can't really do that compartmentalization.
What happens if I don't call close on an object? Will it get collected as garbage? Will I be able to access that object later?
Please let me know if I can further specify my question somehow.
You can't use the query results since you closed them (i.e the List object you got back from query.execute). You can access the objects in the results ... if you copied them to your own List, or made references to them in your code. Failure to call close can leak memory
When your query method returns a single object it is easy to simply close the query before returning the single object.
On the other hand, when your query method returns a collection the query method itself can not close the query before returning the result because the query needs to stay open while the caller is iterating through the results.
This puts the responsibility for closing a query that returns a collection on the caller and can introduce leaks if the caller neglects to close the query - I thought there must be a safer way and there is!
Guido, a long time DataNucleus user, created a 'auto closing' collection facade that wraps the collection returned by JDO's Query.execute method. Usage is extremely simple: Wrap the query result inside an instance of the auto closing collection object:
Instead of returning the Query result set like this:
return q.execute();
simply return an 'auto closing' wrapped version of it:
return new JDOQueryResultCollection(q, q.execute());
To the caller it appears like any other Collection but the wrapper keeps a reference to the query that created the collection result and auto closes it when the wrapper is disposed of by the GC.
Guido kindly gave us permission to include his clever auto closing code in our open source exPOJO library. The auto closing classes are completely independent of exPOJO and can be used in isolation. The classes of interest are in the expojo_jdo*.jar file that can be downloaded from:
http://www.expojo.com/
JDOQueryResultCollection is the only class used directly but it does have a few supporting classes.
Simply add the jar to your project and import com.sas.framework.expojo.jdo.JDOQueryResultCollection into any Java file that includes query methods that return results as a collection.
Alternatively you can extract the source files from the jar and include them in your project: They are:
JDOQueryResultCollection.java
Disposable.java
AutoCloseQueryIterator.java
ReadonlyIterator.java