[Pulp-list] Client Refactoring

[Nick Coghlan]

On 07/21/2011 08:02 AM, Jason L Connor wrote:
>> I think I would prefer the first way.  It would behave a lot like many
>> ORM's
>> do.  The model would have to know it's url, but there could be a lot
>> of code
>> reuse from a base class, such as the create() method, which would be
>> basically
>> the same for almost every model (you just hit a different url).
>
> I like the first idea as well. Simply make the model classes themselves
> be clients of the api library.

That approach couples the client model instances to a specific server, 
though, which doesn't fit well with the planned GlobalSync management model.

I'd like to be able to create a single Repo model instance for a new 
tree that has just been made available on the main server, then submit 
that model separately to all of the sites that are going to mirror the 
new repository. I can create new instances just to change the target 
server (or edit the server details in place), but it seems cleaner to 
keep the two separate.

Alternatively, the SQL Alchemy session model may be useful here. That 
allows you to either invoke operations directly on a DB session, or else 
use an implicit session that is held in thread local storage. For the 
Pulp client API, the global server connection could be used implicitly 
when invoking operations on model instances, with a separate explicit 
mechanism to perform operations against a specific server.

Regards,
Nick.

-- 
Nick Coghlan
Red Hat Engineering Operations, Brisbane