Some little things!!!

[r rad]

Hi,

I have some objections on current quality Jam.py docs.

On https://jam-py-v7.github.io/jampy-docs-v7/intro/admin.html is page about inner structure of the admin.sqlite file. 

I don't know what this to do there, but it is graphically and at more other ways it is unworthy doc for one framework as Jam.py and rest of his docs. 

Secondlly, on https://jampy-docs.readthedocs.io/projects/V7/en/latest/how_to/how_to_implement_a_many-to-many_relationship.html is doc about many to many db relationship, in this case about Customer-Tracks. I don't know, how author imagines an m:n relationship, but it is not shown in any of these views. 

Only partial m:n relations customer(invoce) to tracks, and tracks to customer(invoice) are visible there.

Unfortunately, there are a lot of light-hearted comments like this, especially on this blog. 

Clearly, we are not all the same in terms of active knowledge, education, experience, but I think we should still be a little more careful in giving our opinions and writing facts about Jam.py.

With good intentions,

Radosav

[r rad]

Dean, As far as I can see I was at the same address. In any case, on the page that it defines the relationship m:n well, 

but in the Demo program it is not like that. 

I haven't been in touch with Andrew for years, I asked him to correct a poorly written text for moving around the dataset, 

he scolded me like you did and I've since concluded that I'm clean excess. 

I don't want to interrupt you or anything like that, but if I can't say what I think then I don't belong here. 

As for paying for translation, it has long been customary in the open source world that users translate into their own language, 

if they feel it is necessary. That is the essence, the contribution a little bit of each. 

Otherwise, who will pay me for the translation into Serbian, which is much rarer and much more more complex (at least grammatically) 

than probably 90% of the world's languages like you known after all. Of course, I'm joking about the last one, as you probably know 

I signed the contract with AJ on handing over all rights to him, as soon as we started cooperation 2016-7 years. And I have no problem 

with that. His part is immeasurably greater, my contribution is really small. 

I just tried to say that it might be better to think a little, to read or consult before writing things that are often materially incorrect. 

But it doesn't have to be an obligation either, because in the end everyone tries to help within their capabilities, and the rest, 

and the rest as how-who... 

Only the good intention is important. 

Actually we are talking about Jam.py here. This assistance to users should be of high quality or at least at the level of Jam.py itself 

and its documentation.

Greetings, Radosav

On Monday, 8 June 2026 at 03:40:45 UTC+2 Dean D. Babic wrote:

The admin.html was moved:
https://jam-py-v7.github.io/jampy-docs-v7/contents.html

Or:

https://jampy-docs.readthedocs.io/projects/V7/en/latest/intro/index.html 

No idea why github/readthdocs has a redirect to an OLD location. 

Regarding the other link you posted, have a look:
https://jam-py.com/docs/how_to/how_to_implement_a_many-to-many_relationship.html

Did you ask Andrew regarding this? Because I did. And never got the reply. So instead of 

having a blank page, some description is better than zero imo.

Nothing is stopping anyone to contribute:
https://github.com/jam-py-v5/jam-py-v7/discussions

However, it is easy to just jump and break the automated build on github/readthedocs, which then I need 

to fix for hours.

Btw, the cost of translating Docs to Chinese is AU$1200, or 6000 Yuan. Who will pay him?

I'm not giving away my time any more for free. Simple. If other people do not want to 

contribute for free, why would I?

The Opens Source has changed. Thanks to AI.

[r rad]

Dean,

I worked at Django professionally for 4 years, before retiring. Of course, Django can't be compared to Jam.py, but I like Jam.py.

As for m:n large and small relationships, Django has components and codes that directly support them, and replacements can be found on the net.

But here is not the story about that, but in the explanation what's appears in the documentation or on the blog, about the fact that there is a m:n relationship on the Demo.

So I claim it doesn't exist, at least not in the GUI interface. For something like that, the "Customers" view should have details with all purchased songs for each customer, but there aren't any, and the "Track" should have details with all customers of that song, but they aren't.

There is one slight replacement, relationship via "Invoices", because it is not performed correctly, but as far as "Customer" -> "Tracks" is concerned and vice versa.

After all, I'm not here to impose you or anyone else my opinion, I'm here to say it. There is a ton of material on the net about RDMS relationships, so anyone who is of course interested can read it.

I'll try to make some articles about Jam.py and post them in places where I guess someone will read it. But don't expect too much from me. I'm just an old, tired called programmer, who is beaten by life from all sides.

Besides, I believe that only very accurate and correct information can attract people. Everything else repels them. So no advertising, and nothing like that, just good intentions and correctness, ...

Greetings, Radosav

On Monday, 8 June 2026 at 13:59:29 UTC+2 Dean D. Babic wrote:

Radosav, 

have a look for Django:
https://docs.djangoproject.com/en/6.0/topics/db/examples/many_to_many/

It clearly says:
"In this example, an Article can be published in multiple Publication objects, and a Publication has multiple Article objects"

And then the coding takes over. 

Jam can't compete with Django. You are not correct regarding paying. Django is FUNDED. Just have a look at donations. How much is spent on Docs I don't know, but it costs a lot of money just to run servers with examples. I would know, I spent $$$ of my own money. 

People who work/ed on Jam need encouragement, not a critique. The proof is here:
https://github.com/jam-py-v5/jam-py/discussions/1

See what the user wrote:
"Here is a work that I started some time ago but my problem is that I can't finish it due to a lack of inspiration and encouragement."

These are not my words, but you get the idea.

Hence, here is a question:

- how would you display m:n relationships in Jam that would attract users these days? 

[r rad]

This is NOT TRUE. This is NOT Customer -> Tracks relationships, but Customers -> Invoice. 

And only one side. :(

Dear my Dean, I think, sorry for the honesty, that you are not enough in the matter. 

Or is it something else, but that's something else for others... 

I will no longer reply to your posts or ask questions. 

There is no one to answer them anyway, either because they don't know or because they won't. 

I'll just try to present a little something here and there from time to time!

Greetings from beautiful Serbia, Radosav.

PS. Thank you for your good wishes regarding retirement. 

You will see how much it means once you get into that position.

On Monday, 8 June 2026 at 16:05:33 UTC+2 Dean D. Babic wrote:

I have no comment. It took me 30 seconds to prove that you are wrong.

https://jampy.pythonanywhere.com/

Enjoy your retirement.

[r rad]

Son, It is almost a Customer to Track m:n relationship, but it is not. 

As I said, your knowledge is very far-fetched, you probably picked up the knowledge from an evening course. 

The same song titles appear in multiple lines. :( 

So by definition it would be a relationship of one customer on several songs, but not on several repeated songs. 

I have an idea, if you wipe off those excesses and the matter will go to bed, son? :( 

Son, still nothing about the other side of the relationship, Track to Customer. 

Don't bother me anymore, because you will get an honorary blacklist item, which I have never given to anyone in all these years. 

Uncle Radosav

PS. As for my barking, thank you. And you probably picked that up on that "evening" from the course. :(

On Tuesday, 9 June 2026 at 08:35:05 UTC+2 Dean D. Babic wrote:

So where is the problem? 
Radosav, you are barking on the wrong tree. This has NOTHING to do with v7.
It is a basic Jam functionality from years ago.