You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@pig.apache.org by Apache Wiki <wi...@apache.org> on 2008/05/21 17:13:18 UTC

[Pig Wiki] Update of "PigContextAbuse" by AlanGates

Dear Wiki user,

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

The following page has been changed by AlanGates:
http://wiki.apache.org/pig/PigContextAbuse

------------------------------------------------------------------------------
  
  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 registered,
+ properties specified for the job, connection to an execution engine and/or file system, and any information about jobs running on that execution engine.  The
+ 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 information,
+ 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.
+