You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We can not ignore service building if we really want OJ-lab to be online.
And services are more likely to be refactored for many times in the future, if we make mistake when we take our first step.
I'm going to describe the general functionality request for OJ-lab in this section, in order to present a brief design.
Please feel free to give either suggestions | point fix here.
System Structure
There are three main parts of codes to make the whole OJ-lab to work:
Platform service code (backend, in which we organize the website data and present online-judge business)
Platform client code (frontend, in which we show our user interface)
Judger agent code (judge machine which support flexible deploy by k8s | docker | native method)
Platform service code is the most important one, for it's the center controller of OJ-lab. And that's why I put this topic in oj-lab-services repository.
About Entities
Entities are datas we often stored in database (usually a table) but also sometimes record in some other ways. OJ-lab's platform service will do CRUD for these entities while user | system action take place, so that it can present | save data changes and make the whole system run.
We need to figure out necessary segment for each entities, in order to prevent from circumstance that a new segment effect old entities which didn't have it.
Common Relational Database Entities
There are some shared common sense for entites which store in relational database, so that we can build the system easier.
About primary key: I don't like ordered primary key in numeric type (for in most cases primary key indicate nothing, including the ordering information), so I decide to use UUID for primary key by default
About time: create & update time are necessary for most of the entities (even it seems to be useless, we put an annoymous one first)
Should be noticed that a problem can have several test case set, but only one of them can be effective for public.
The folder structer for one problem's test cases should be:
/Problem_1
--/TestCase_UUID_1
--/TestCase_UUID_2
----settings.json
----1.in
----1.out
For public when TestCase_UUID_2 is set to the effective one public judge request will use TestCase_UUID_2 by default, but for managers, they can try TestCase_UUID_1 from privilege actions.
P.S.
A Judger is a machine which provide judge services, it a least expose one service address for the platform to call.
Provider help the platform service to control the Judger instance (for Docker | Kubernetes type Judger, we can stop the container by API, and for Native Judger we just stop the process)
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
We can not ignore service building if we really want OJ-lab to be online.
And services are more likely to be refactored for many times in the future, if we make mistake when we take our first step.
I'm going to describe the general functionality request for OJ-lab in this section, in order to present a brief design.
Please feel free to give either suggestions | point fix here.
System Structure
There are three main parts of codes to make the whole OJ-lab to work:
Platform service code is the most important one, for it's the center controller of OJ-lab. And that's why I put this topic in oj-lab-services repository.
About Entities
Entities are datas we often stored in database (usually a table) but also sometimes record in some other ways. OJ-lab's platform service will do CRUD for these entities while user | system action take place, so that it can present | save data changes and make the whole system run.
We need to figure out necessary segment for each entities, in order to prevent from circumstance that a new segment effect old entities which didn't have it.
Common Relational Database Entities
There are some shared common sense for entites which store in relational database, so that we can build the system easier.
User
Id
: UUIDName
: StringEmail
: StringEncryptedPassword
: StringEncryptSalt
: StringCreateTime
: TimestampUpdateTime
: TimestampProblem
Id
: UUIDTitle
: StringDescription
: StringSourceId
: UUIDTagIds
: [UUID]EffectiveTestCaseId
: UUIDDifficulty
: 0~100 FloatCreateTime
: TimestampUpdateTime
: TimestampShould be noticed that a problem can have several test case set, but only one of them can be effective for public.
For public when TestCase_UUID_2 is set to the effective one public judge request will use TestCase_UUID_2 by default, but for managers, they can try TestCase_UUID_1 from privilege actions.
Judger
Id
: UUIDAddress
: JSON {IP: String, Port: Int}Provider
: Native | Docker | KubernetesCreateTime
: TimestampUpdateTime
: TimestampBeta Was this translation helpful? Give feedback.
All reactions