stevearc / flywheel

Object mapper for Amazon's DynamoDB
MIT License
128 stars 25 forks source link

Problem with Composite ... #7

Closed eprparadocs closed 10 years ago

eprparadocs commented 10 years ago

Here is my schema...

__metadata__ = {
   'global_indexes': [
        GlobalIndex.all( 'gcc-index','_country_code' ),
        GlobalIndex.all( 'gat-index','_app_type' )
    ]
}

_country_code = Field( data_type=STRING )
_app_type = Field( data_type=STRING )
_app_id = Field( data_type=STRING )
_app_version = Field( data_type=STRING )
_full_appid = Composite( '_country_code', '_app_type', '_app_id', '_app_version', data_type=STRING,  hash_key=True )
_analyzer_name = Field( data_type=STRING, range_key=True )
_data_type = Field( data_type=STRING, index='ldt-index' )
_creation_datetime = Field( data_type=datetime, index='lc-index' )

def __init__( self, country_code=None, app_type=None, app_id=None, app_version=None, analyzer_name=None, data_type=None, creation_datetime=None ):
    self._country_code = country_code
    self._app_type = app_type.lower() if app_type else None
    self._app_id = app_id
    self._app_version = app_version
    self._analyzer_name = analyzer_name
    self._data_type = data_type
    self._creation_datetime = creation_datetime or datetime.utcnow()

When I set initialize everything and do a 'eng.save()' I get the following error returned:

boto.dynamodb.exceptions.DynamoDBNumberError: BotoClientError: TypeError numeric for <flywheel.fields.Composite object at 0x9eece2c> Cannot convert <flywheel.fields.Composite object at 0x9eece2c> to Decimal

This must be wrong.

stevearc commented 10 years ago

There's two things going on here, a documentation bug and an API bug. Right now, Flywheel intentionally disables certain functionality for private fields (starting with '_'). The first problem is that this isn't documented, and it really should be. The second problem is that it's not intuitive and should behave better. That's just poor design on my part.

I'm making a change at the moment which will fix your issue and then I'll update the docs accordingly. I should have this in today and I'll release 0.1.2 some time tomorrow. If you need the model working before then, you can temporarily remove the leading underscore from all the fields. Thanks for finding this issue!

stevearc commented 10 years ago

0.1.2 is released on pypi.

Just to clear up all the edge cases, your current model should now work. Fields will not work if they begin with a double-underscore or end with a single underscore.

class MyModel(Model):
    f1 = Field()  # this is fine
    _f2 = Field()  # this is also fine
    f3_ = Field()  # this will throw an error with a reasonable message
    __f3 = Field()  # this will also throw an error with a reasonable message

If you are using undeclared fields, any field that begins or ends with an underscore will not be persisted to Dynamo.

instance.other_field = "this field will be saved to dynamo"
instance._foobar = "this field will not"
instance.foobar_ = "neither will this"
eprparadocs commented 10 years ago

Thanks for the information. I looked at the dynamodb spec for column names and thought they were OK.

Peace Chuck Wegrzyn

Sent from Yahoo Mail on Android