Yeah this makes sense, let's make a branch of the current working code, like a V01.XX.XX and generate a docker image for that so people can force their server to run that code.

And you can just merge my current json API branch into this Server V2 branch if you want a head start. Once that's done we can close my branch and Implement json API as part of V2 and not have any in V1

You want a hard cut-over? The way I wrote the current requests, we could still have both parts running, and be future-proof (v3,4,5...) too.
But yea I will merge your current branch into this one

I think something as big as an API changing structure would be enough to do a hard cut-over, it's your call in the end but I think V2 being the version with the big API change makes sense to me and then we just leave the old version alone, maybe patch it every now and then if we need to but otherwise leave it alone.

Also do you want to take the lead on the server side of V2 then? That'll let me focus on doing the frontend V2 implementing all these manga pop-up and search/add pop-up changes that everybody's been wanting. I can also then implement any other changes as a result of the server V2. What do you think?

Sounds like plan!
So it would essentially be complete V2 front- and backend, then a hard cut-over would make a lot of sense.

Hi 👋
Happy holidays!

Since I have some free time, is there a list of stuff that needs to be done to push forward either tranga or tranga-website? (Not promising anything but I'll try)

Hey @ale-ben, thanks for the offer! Happy Holidays! I think on the front end, the current pure JavaScript + CSS needs to be migrated over to the react + Typescript format.

Thanks for the reply @db-2001!
As far as I can tell, the migration to react + ts has already begun in the vite-react-ts branch. Am I wrong?

What still needs to be done?

Btw, if u want to add me on discord here's the link https://discord.gg/jS94ybbn

Hi @ale-ben !
Yes the frontend rewrite has moved to vite-react-ts.
For the most part things kind of work.
The Backend is in pg-v2 and is a postgres-database rewrite with ASP.NET Endpoints.
If you build it, a swagger doc should be generated with the endpoint-names. Functionality is not really there yet (searching works), as Entity Framework Code-First and Lazyloading are a bit of a pain to get to work correctly, but that is currently the biggest front of my workload.

Ok, thanks for the update!
I'll try cloning pg-v2 and see what happens.

Since v2 branch is pg-v2 I'll close #308

I might have lied, it is postgres-server-v2 (a merge between both attempts) ;)
https://github.com/C9Glax/tranga/tree/postgres-Server-V2

Ok, it took a while due various compilation problems but finally I got the API working!

The main problem now is that frontend refuses to communicate with the API. It keeps getting stuck here:
https://github.com/C9Glax/tranga-website/blob/0402f9e6d003601b0f6976b8638c390d38cb8e69/Website/App.tsx#L129

Frontend tries to call {apiUri}/v2/Ping but I can find no mention of this endpoint here...

Am I missing something or is this endpoint not implemented yet?

@ale-ben
Haven't updated the frontend in a minute, so that Endpoint doesn't exist yet.

@C9Glax

I'm kind of stuck, I pulled the latest changes from postgres-Server-V2 and now nothing seems to work.

I am trying to run the project but I keep getting this error:

handled exception. System.InvalidOperationException: No suitable constructor was found for entity type 'Chapter'. The following constructors had parameters that could not be bound to properties of the entity type: 
    Cannot bind 'parentManga', 'chapterNumber' in 'Chapter(Manga parentManga, string url, ChapterNumber chapterNumber, int? volumeNumber, string title)'
    Cannot bind 'chapterNumber' in 'Chapter(string parentMangaId, string url, ChapterNumber chapterNumber, int? volumeNumber, string title)'
Note that only mapped properties can be bound to constructor parameters. Navigations to related entities, including references to owned types, cannot be bound.

I tried everything that comes to mind (except for moving my head back a couple of commits):

• erased everything and cloned back from postgres-Server-V2
• dropped the pgsql db tables to have a fresh start
• stared intently at the code
• tried talking it out with dave (my rubber duck)
• (in progress) tried in a different machine

What am I missing?

You are missing my untested changes to Chapter.cs... So nothing really apart from my own stupidity.
Basically I tried implementing a new number-type for Chapters like "5.3.5", but haven't gotten it to work with the database yet.

Give my regards to Dave, he tried his best but could not fathom my incompetence :)
This is the commit btw that breaks it. (I think).

I am gonna very busy for the coming 2 months at least, so apart from fixing bugs on the current branch, I am not gonna really be able to make a lot of progress... So if you wanna go wild, now is the time 👍🏼

Ok, thanks for the info, I'll see what I can do. I will open a PR if I accomplish something.
What was the idea behind using a custom structure to represent chapter number instead of a simple string?
With some simple comparison tricks you could obtain the same results...
Mind if I give a try to the string route?

Go right ahead!

There seems to be something very wrong with Jobs...
I'm trying DownloadSingleChapterJob. The job is started and set as running but never marked as completed, and every couple of seconds a new job is spawned. Neither Dave nor I can figure out why.

@C9Glax Do you have any Idea?

Just a quick hunch:
The spawning is happening because we get Job (-states) from the PGSQL context, which we need to updated, should we change anything in the Job-Object, which we are not at the moment. So Tranga.cs Line 79 List<Job> runJobs = context.Jobs.Where(j => j.state <= JobState.Running).ToList().Where(j => j.NextExecution < DateTime.UtcNow).ToList(); still returns the old state, which is kind of a pain tbh...

What probably is the best idea (threading, database updates, yadada), is to have a separate copy of the Jobs, that we then sync with the database after every check? That way changes to the Job-Objects can be made independent of the pgsql context and still be up-to-date enough for other applications?

The solution appears to be quite simpler than what either of us expected (I feel like Dave knew though...)!
Preventing a thread to be spawned if a job with the same ID exists in RunningJobs apparently is enough to give the job time to sync the new state with pg.
This is the only thing I had to do: https://github.com/ale-ben/tranga/blob/dd1d67ac1190ae2c8af6e2537f672c271b819160/API/Tranga.cs#L85-L86

My formatter is quite aggressive and I haven't figured out how to tune it yet, sorry if some files are reformatted...

I opened a draft PR to track the changes between my branch and the official repo, you can follow my progresses here: #317

Unfortunately, with every solution comes a new problem...

I just noticed that creating identifiers using random numbers has a huge downside, if you search multiple times for the same manga (using the same connector), pg will have multiple entries (one for each search) for the same manga.
This could lead to incoherent results down the line...
As far as I know, this also extends to Chapters (multiple download all jobs generate multiple chapters for the same chapter).

I would suggest going back to using non-random based IDs like V1 used to do (for example Manga-[MangaConnectorId]-[ConnectorId]).
The only alternative I can think of would be before each operation (search manga, get chapters, ...) to verify if the entity exists in the context but it is a lot more expensive than just generating Ids based on something.
What do you think?

Nice!
On the formatter part: can you configure it to use strongly-typed Variable-Types? I really dislike the "var" stuff. It reallyesses with readability...

pg will have multiple entries (one for each search) for the same manga.

Yes, the primary Key should consist of ConnectorId and MangaConnectorId), or if we want to adhere to a standard-naming-scheme - which is why I introduced this anyways, a Hashing function taking those two...

Nice, I was hoping for hashing IDs!
Should we keep the initial descriptor (Manga-, Chapter-, ...) and hash the last part or just drop the descriptor?
Will start on it immediately.

Formatter is fixed btw

Also, sorry for the continuous pings...

Should we keep the initial descriptor (Manga-, Chapter-, ...) and hash the last part or just drop the descriptor?

That's the idea 👍🏼

Don't worry about the pings, this is better than working on stuff for a few hours and then disagreeing on how to do something.