Skip to content
This repository has been archived by the owner on Aug 27, 2023. It is now read-only.

Problem with Composite ... #7

Closed
eprparadocs opened this issue Mar 10, 2014 · 3 comments
Closed

Problem with Composite ... #7

eprparadocs opened this issue Mar 10, 2014 · 3 comments

Comments

@eprparadocs
Copy link

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
Copy link
Owner

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
Copy link
Owner

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
Copy link
Author

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

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants