Skip to content
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

Open
gregtap opened this issue Oct 6, 2012 · 17 comments
Open

DateTimeField and auto_now_add=True #48

gregtap opened this issue Oct 6, 2012 · 17 comments

Comments

@gregtap
Copy link

gregtap commented Oct 6, 2012

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.

@yohanboniface
Copy link
Collaborator

Yes, typed fields could be a good time-and-LoC saver when using redis.
I think limpyd core should only provide a "cast" hook (something like to_python, to_storage, which do nothing by default), and then we can add such typed field (DateTime, Int...) in the /contrib module.
As I regularly said to @twidi, I think we must try to keep the limpyd core simple and with a good API, and provide some useful tools in contrib module. :)

@twidi
Copy link
Collaborator

twidi commented Oct 6, 2012

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.

@stuaxo
Copy link

stuaxo commented May 11, 2016

Hi,
Typed fields would be great, is there any progress on this? If they exist, I have some I'd like to add..

S

@twidi
Copy link
Collaborator

twidi commented May 12, 2016

I totally forgotten this, and, sadly, I have absolutely no idea where my draft is :-/

So no, no news on this, sorry.

@stuaxo
Copy link

stuaxo commented May 12, 2016

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 return int(result) - any hints ?

@stuaxo
Copy link

stuaxo commented May 12, 2016

Doh, worked something out, sorry for the noise.

@twidi
Copy link
Collaborator

twidi commented May 12, 2016

:)

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 contrib part, or maybe it could be in a separate repository as we did for limyd-extensions)

@stuaxo
Copy link

stuaxo commented May 12, 2016

Yup - nothing generic right now, just a POC where I overrode the get method.

Are these assumptions correct:

  • get isn't the only method that can return a value
  • some methods might return more than one value

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)

@stuaxo
Copy link

stuaxo commented May 12, 2016

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).

@twidi
Copy link
Collaborator

twidi commented May 12, 2016

Your assumptions are correct.

But you're "lucky": each field has two attributes available_getters and available_modifiers. They hold the names of the command that are allowed to get/set data.

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.

@twidi
Copy link
Collaborator

twidi commented May 12, 2016

Do you think Sider (I don't know this lib) could be plugged with Limpyd?

@stuaxo
Copy link

stuaxo commented May 12, 2016

But you're "lucky": each field has two attributes available_getters and available_modifiers. They hold the names of the command that are allowed to get/set data.

I had a look at available_getters, but not every one of those would need transforming, e.g. in StringField: available_getters = ('get', 'getbit', 'getrange', 'strlen', 'bitcount', )

Do you think Sider (I don't know this lib) could be plugged with Lipmyd?

Maybe .... it would involve some rewriting, OTH both projects are basically missing what the other provides.

https://sider.readthedocs.io/en/0.3.1

@twidi
Copy link
Collaborator

twidi commented May 12, 2016

About the getters, let's imagine you create your field based on a StringField, you can set yoursel the available getters and setters of your field. Because calling getbit on a DateTimeField doesn't make any sense.

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 :(

@stuaxo
Copy link

stuaxo commented May 12, 2016

I guess it's a similar story for modifiers ?

@twidi
Copy link
Collaborator

twidi commented May 12, 2016

yes of course

@stuaxo
Copy link

stuaxo commented May 13, 2016

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

@stuaxo
Copy link

stuaxo commented May 16, 2016

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.

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

No branches or pull requests

4 participants