-
Notifications
You must be signed in to change notification settings - Fork 11
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
DateTimeField and auto_now_add=True #48
Comments
Yes, typed fields could be a good time-and-LoC saver when using redis. |
I have (beginning of) code for this in a draft somewhere, maybe one day i'll made a PR with code and tests and some basic fields. |
Hi, S |
I totally forgotten this, and, sadly, I have absolutely no idea where my draft is :-/ So no, no news on this, sorry. |
I realise you're busy. .. just one thing though; I'm trying to look at the feasibility of typed fields: I copied StringField to IntegerField, but am having a bit of trouble working out where to put the code along the lines of |
Doh, worked something out, sorry for the noise. |
:) If you have something that works, is generic enough to ease the creation of other typed field, and is tested, I would love to take a look and maybe integrate it (in the |
Yup - nothing generic right now, just a POC where I overrode the get method. Are these assumptions correct:
Assuming the above, I need to add a list of which fields are getters + need results to be transformed and any that return sequences of results (and need to transform each one). Ungeneric version: class IntegerField(StringField):
to_python = int
def get(self):
result = super(IntegerField, self).get()
return self.to_python(result) |
Given infinite time, Sider looks like a great option for handling types (it seems to have no ORM, it just does redis <-> python type conversion). |
Your assumptions are correct. But you're "lucky": each field has two attributes But it will be cumbersome to work on each of these getters and setters. In a "long term thinking", the first thing to do I think is to add a way in the internals of limpyd, to have a hook that intervenes before a setter, and after a getter. |
Do you think Sider (I don't know this lib) could be plugged with Limpyd? |
I had a look at available_getters, but not every one of those would need transforming, e.g. in StringField:
Maybe .... it would involve some rewriting, OTH both projects are basically missing what the other provides. |
About the getters, let's imagine you create your field based on a So, first, with these attributes you can learn what are the default getters and setters, redefine these attributes in your field class without the ones that don't make any sense, and override the setters and getters methods to do what you want. PS: I checked on my current and previous computer for my old work on this subject, without success :( |
I guess it's a similar story for modifiers ? |
yes of course |
I've been experimenting in this branch https://github.com/stuaxo/redis-limpyd/tree/sider-types It's not uber clean, but there is an ipython notebook I've been trying stuff in. It creates typed.IntegerField and others by wrapping the Sider types, though I've only really tested IntegerField and BooleanField for get and set so far. to_storage is more tricky than to_python, as it's not obvious which field is going to be a value, there is the start of some code for it, but not hooked up. The only code in lympid itself is a flag to let you override _make_command_method - kind of clunky, but it works: https://github.com/stuaxo/redis-limpyd/blob/sider-types/limpyd/fields.py#L95 |
While I got quite a bit working, as I'm on a tight deadline, I switched tack and got redisco working on python3 (as I'm getting existing features working there, not adding new ones). I can definitely help to polish this, up, but it's still a bridge. A proper fix would be more tightly integrated - or go the other way and add the missing features to Sider. |
Would be nice, for now I store date as isoformat() in string and do the logic on my side.
I may give it a try but I wonder how the sorting will behave.
The text was updated successfully, but these errors were encountered: