[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [Pulp-list] Client Refactoring



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


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]