Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Pig Wiki" for change 

The following page has been changed by AlanGates:

  Object instantiation is tightly coupled with other parts. We should add 
another utility class that just does object instantiation by using the 
properties inside PigContext like the extra jars that were added during the 
execution of Pig. With this infact the PigContext class becomes redundant. This 
can be maintained as a variable of type properties in PigServer, as a mapping 
from the execution engine. The PigServer can have a variable currentExecEngine 
which points to an entry in the mapping. So all accesses to PigContext can then 
be replaced by a Properties object. However this would mean that PigServer will 
be the starting point for any operation. I guess that is the way it should be.
+ == Comments ==
+ === AlanGates 21 May 2008 ===
+ I think it makes sense to associate data store handles, job configuration, 
properties, and jar registration with a given session.  I like your idea of 
having a separate utility to handle
+ object instantiation.  I also agree that !PigServer should be the central 
point for accessing this information.  So maybe it makes sense to have something
+ like this.  There is a !PigSessionContext class that holds all information 
relevant to a particular session.  This would include jars that have been 
+ properties specified for the job, connection to an execution engine and/or 
file system, and any information about jobs running on that execution engine.  
+ set of all !PigJobContext objects would be kept in !PigServer, in a map keyed 
by a session id.  This way we can get access to all relevant session 
+ internally or externally, and we need only pass around the session key.  For 
now, there will always only be one session, but as we move to a client-server
+ architecture in the future that can change.

Reply via email to