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

fix uploads, i.e. use binary instead of base64 #155

Open
niphlod opened this issue Apr 28, 2015 · 5 comments
Open

fix uploads, i.e. use binary instead of base64 #155

niphlod opened this issue Apr 28, 2015 · 5 comments

Comments

@niphlod
Copy link
Member

niphlod commented Apr 28, 2015

No description provided.

@mdipierro
Copy link
Contributor

I am ok to have a flag to use one convention or the other.

@gi0baro gi0baro added this to the 15.09 milestone Jul 2, 2015
@niphlod
Copy link
Member Author

niphlod commented Jul 13, 2015

gave a hard though about this: unfortunately each - major - adapter has its own wrapper implementation to read file and insert into a binary.
The thing is, pydal (or, better said, DAL) was initially engineered to work around bugs in several adapters, bug that ATM are totally fixed.
I'm talking about constructing its own statement instead of using prepared statements with parameters. If we want this integration to succeed, at least the insert and the update API should be converted to use placeholders instead of relying on DAL's own serialization to string before piping it into the adapter.

@gi0baro
Copy link
Member

gi0baro commented Jul 15, 2015

@niphlod do you think is a good way to proceed?

@niphlod
Copy link
Member Author

niphlod commented Aug 4, 2015

see also this . https://groups.google.com/forum/#!topic/web2py/Q5q-FpZd8qc .
@gi0baro : dunno, let's hear from @mdipierro . IMHO pydal "preparation" should be overridden in each adapter able to take parameters.

@mdipierro
Copy link
Contributor

I think it makes sense that we do this. I agree we can stick to insert and update first.

@gi0baro gi0baro modified the milestones: 15.09, 15.10 Sep 28, 2015
@gi0baro gi0baro removed this from the 16.01 milestone May 9, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants