Missing pieces?

[Rasjid Wilcox]

Hi there,

Still exploring Prestans, so maybe I've just missed something, but for me there seems to be a couple of things missing from Prestans.

The model adaptors seem to be for a list of persistent objects -> json representations.  I could not find anything (ie, a single function equivalent to QueryResultIterator) for adapting a single persistent object to a single json representation, such as might be required for the 'get' of a single object.  Now, this was not hard to write, and is just a minor variation on the existing code, but to me seems like a gap in the API given that it should be a fairly common operation.

I also can't see anything going the other way - ie, for adapting json representations to persistent objects, such as would be required for a 'put'.

If I've missed something obvious, please let me know.  If not, I'll finish up versions at least for sqlalchemy and share.  I assuming that the best way to share would be via a fork on GitHub, although just as happy to post bits of code to the list.

Cheers,

Rasjid.

[Devraj Mukherjee]

Hi Rasjid,

On Thu, Mar 21, 2013 at 12:12 AM, Rasjid Wilcox <ras...@gmail.com> wrote:

The model adaptors seem to be for a list of persistent objects -> json representations.  I could not find anything (ie, a single function equivalent to QueryResultIterator) for adapting a single persistent object to a single json representation, such as might be required for the 'get' of a single object.  Now, this was not hard to write, and is just a minor variation on the existing code, but to me seems like a gap in the API given that it should be a fairly common operation.

You haven't missed anything here. True that prestans does not have the ability to adapt a single object, and I agree that that we should.

 

I also can't see anything going the other way - ie, for adapting json representations to persistent objects, such as would be required for a 'put'.

We used to have this in an earlier working version. Problem was partial updates, if the client sent values that you didn't wish updated on the server side the adapter would go through and update them anyway.

Since the introduction of Attribute Filters we should be able to restore this in a much more elegant way.

Let me put some thought to this. 

 

If I've missed something obvious, please let me know.  If not, I'll finish up versions at least for sqlalchemy and share.  I assuming that the best way to share would be via a fork on GitHub, although just as happy to post bits of code to the list.

Posting the code on the list is fine. I can patch 1.1

Thanks for taking time to share your thoughts and code.

[Rasjid Wilcox]

On Thursday, 21 March 2013 08:52:34 UTC+11, Devraj wrote:

On Thu, Mar 21, 2013 at 12:12 AM, Rasjid Wilcox <ras...@gmail.com> wrote:

I also can't see anything going the other way - ie, for adapting json representations to persistent objects, such as would be required for a 'put'.

We used to have this in an earlier working version. Problem was partial updates, if the client sent values that you didn't wish updated on the server side the adapter would go through and update them anyway.

I would have thought that the best way to solve that issue is that in the REST model, certain attributes are declared as 'read only' attributes, with the server probably returning a status 400 if a client sends a request (put, post or patch) that modifies them in any way.

Actually, it might be better to flip it around and have an 'updatable' property for REST model attributes, which could be 'Always', 'Never' or 'Create_Only', the latter being relevant particularly for puts that might specify the primary key of an object.

Cheers,

Rasjid.

[Rasjid Wilcox]

On Thursday, 21 March 2013 08:52:34 UTC+11, Devraj wrote:

On Thu, Mar 21, 2013 at 12:12 AM, Rasjid Wilcox <ras...@gmail.com> wrote:

The model adaptors seem to be for a list of persistent objects -> json representations.  I could not find anything (ie, a single function equivalent to QueryResultIterator) for adapting a single persistent object to a single json representation, such as might be required for the 'get' of a single object.  Now, this was not hard to write, and is just a minor variation on the existing code, but to me seems like a gap in the API given that it should be a fairly common operation.

You haven't missed anything here. True that prestans does not have the ability to adapt a single object, and I agree that that we should.

Here is my current code, just adapted from the current QueryResultIterator function in the sqlalchemy module.  I've not put in any error checking yet since I'm currently unclear at what level the error checking should be done.

def adapt_persistent(persistent_object, target_rest_instance=None, attribute_filter=None):    
    """ Try and get the adapter and the REST class for the persistent object """
    if target_rest_instance is None:
        adapter_instance =  prestans.ext.data.adapters.registry.get_adapter_for_persistent_model(persistent_object)
    else:
        if inspect.isclass(target_rest_instance):
            target_rest_instance = target_rest_instance()
       
        adapter_instance = prestans.ext.data.adapters.registry.get_adapter_for_rest_model(target_rest_instance)
       
    return adapter_instance.adapt_persistent_to_rest(persistent_object, attribute_filter)