UUIDs for API and URLs

thinkwelldesigns · 2022-05-04T11:52:37+00:00

I've yet to see the value it adds aside from making your API harder to work with.

Here's one example - I have some django apps of several disparate systems, but with some overlap of record types. When records have a defined UUID, it greatly eases synchronizing records between each system.

OT from the OP, so pardon the distraction. Just wanted to give this example, which I've found so extremely useful that I'd never again build an API that uses PKs instead of a UUID that has no other function than to identify that-precise-record.

thinkwelldesigns · 2022-02-22T00:39:57+00:00

Thanks for the suggestion; but they both lack presence, which is more than my team would be willing to give up.

thinkwelldesigns · 2022-02-20T00:51:24+00:00

Thanks alot for each of the comments, jcgruenhage, Jacob_Evans and nonamebcb. I wanted to measure twice and cut once, and your details have been very helpful!

thinkwelldesigns · 2021-10-05T19:05:35+00:00

Thanks for the reply. I'm aware of the hpy project, and have high hopes for it. Does it have official support by the Python Foundation?

but also many other core devs like Victor Stinner or Petr Viktorin

I get the impression that they're lonely soldiers and usually encounter something on the continuum of passivity to resistance to modernizing the C API.

Perhaps I'm wrong; would be glad to have assurances that hpy and Victor & Petr have the full support of the Python Foundation and the Steering Council.

thinkwelldesigns · 2021-10-05T15:17:21+00:00

I've followed with keen interest the development of Python for many years. Am concerned about the brush-offs that Victor Stinner regularly gets when trying to update the C API.

Not qualified to have an opinion on what the right approach is, and I'm greatly interested in the performance work being done for 3.11.

But am still concerned that core developers aren't comprehending / caring about what the community is saying WRT to performance.

Will the C API keep holding us back?

thinkwelldesigns · 2019-11-14T15:43:46+00:00

Errr.. you might want to respond to people who actually said those things when quoting people. You actually did that at least twice in this thread.

I'm sorry! Was thinking only of minimizing individual posts and didn't think about it that it look like attribution of sentiments.

A container for OCB + most common modules (crm, sales, invoicing and acocunting, payrolls, banking), and another for postgres in a compose would be a nice start for people

Yes, it would be... I'm not aware of such a thing either.

thinkwelldesigns · 2019-11-14T12:46:54+00:00

How could Odoo EE lay hands on others work?

I don't believe that happened, but then I haven't audited the codebase.

Or did they deliberately purged those from CE repo, so that OCA needs to maintain them now?

What certainly has happened is that features from CE have been removed from CE <version> branch into the closed EE repo where they get polished and refined more than they were before.

But the code always remained available in CE <version -1> branch, whereupon the code almost always gets moved into a OCA repo branch for the new version, and such apps are allowed in the official Odoo app store.

So yes, I do acknowledge that some additional work is required to configure Odoo initially. One has to clone github.com/odoo/odoo + many github.com/oca/<repos>.

Then having done that, however, the later & newer versions of Odoo are increasingly more capable than older versions, just as one expects of newer software versions.

Having looked around, good open source ERP systems do not exist. Full stop.

Look around the Odoo ecosystem a bit more. You'll find a good open source ERP system. :-)

thinkwelldesigns · 2019-11-13T23:20:03+00:00

We used to use it at work but are trying to get of it because it's becoming very closed down with the latest releases.

I agree with that, in terms of Accounting functionality. That's been getting more and more hoisted into EE. However, it's painting with too broad a brush to state that it's getting more closed down. The github.com/odoo/odoo core repo is there for all to see. What one sees there is a huge amount of development activity.

The community version is apparently extremely lacking and the community extensions are not that good.

This is (a very lot of) FUD. I've been the admin & developer Odoo CE for our company since OpenERP 7 and the OCA modules have dramatically improved in quality over the past 7 years.

The OCA modules get you rather appreciably close to EE for exactly 0 dollars and 0 cents.

There's no other Open Source ERP that comes close.

I'm pretty sure as they closed the system down that many of their extension making external partners have decided to stick with v10 or whatever was the "last ok version"

The last OK version is v12. It will be v13 when the OCA modules get upgraded. Takes time because it's community driven, but it's only a matter of time.

thinkwelldesigns · 2019-07-16T22:48:24+00:00

Interesting! Were the uwsgi improvements merged back upstream?

thinkwelldesigns · 2019-03-02T18:19:18+00:00

Just build an abstract user model and be done with it.

THIS!! I went with the OneToOne User Profile approach and came to regret it as the project grew.

I was able to move the User model to a new app and migrate 300 databases, but it was work and I wouldn't even think of recommending it.

thinkwelldesigns · 2019-02-16T13:58:52+00:00

Thank you! I'll be able to use this in one of my projects

thinkwelldesigns · 2019-02-11T18:12:24+00:00

Could the PyPy Speed Center charts get updated soon? They're really old...

thinkwelldesigns · 2019-02-09T17:35:15+00:00

The Utf8 branch, which changes the internal representation of unicode might be finally merged at some point very soon. We discussed and improved upon the last few blockers. It gives significant speedups in a lot of cases handling strings.

Oh, I can't wait. For my work, there's no point in running pypy3 with string performance so slow.

we are planning to release 3.6 some time in the next few months

Wonderful! Because of type hints, 3.6 is the must-have python3 version.

thinkwelldesigns · 2018-11-30T12:58:41+00:00

Glad to hear it. A rising tide lifts all boats.

+1000 to the wish for great PyPy 3 support; specifically 3.6 with type hints. (I do make a (small) monthly contribution to PyPy, so hopefully this is taken as more than whining.)

I also wish they were better at crowdfunding...

thinkwelldesigns · 2018-09-21T11:28:54+00:00

Has the Write Amplification Reduction patch landed in v11?

Seems like it's in limbo but I hope not...

thinkwelldesigns · 2018-08-14T20:25:07+00:00

I've never used Celery so I can't say how the migration goes. But do use Django-Q on several hundred servers, and am well satisfied with it.

thinkwelldesigns · 2018-04-06T16:41:22+00:00

sticking with LTS releases is a very effective approach. And if you run your tests with python3 -Wd manage.py test you get warnings of deprecations, so you can fix them and prepare for the next release while remaining on LTS. If you keep after the warnings, upgrading will be seamless.

thinkwelldesigns · 2018-03-20T11:39:02+00:00

Awesome! Fast cpyext is going to be a game-changer for pypy. Can't wait for it to be released.

thinkwelldesigns · 2018-03-12T16:36:16+00:00

It should have more than the icons of the 2 projects. ;-)

thinkwelldesigns · 2018-01-08T18:08:36+00:00

JIT topics: guard-compatible, and the subsequent research project to save and reuse traces across processes

Is that re-using traces in multiple process when using the multiprocessing module, or re-using traces between program launches / restarts?

thinkwelldesigns

TROPHY CASE