Grails database table version control - database

I have just started a new database project to price customer bid proposals:
Some of the tables in the database will contain information that is regularly updated say for example the pricing tables.
Now new bids should always use the latest information on the database, however existing bids should continue with the data used when they started unless the bid author decides otherwise.
Matters are somewhat simplified as a bid will under no circumstances use prices across versions so even if a product was coasted and available on an older version of the pricing table, it will not be available to newer projects.
In order to achieve this I am planning to include a version column and perhaps a linked version control table. I think this will be enough.
However I feel like this must be a common database design requirement and thus there must be existing “best practices” and techniques to achieve this so I’d rather build on existing experience than poorly reinvent the wheel.
Any advice on how to resolve this problem? Also I am working with the Grails platform so any Grails specific information would be much appreciated.
I'm not sure I explained my problem correctly so here is an example:
class Bid { // Each new customer bid is stored in this table
String bidName
static hasMany = [ item: ItemList ]
static belongsTo = [ versionNumber: VersionControl]
}
class ItemList { // Products/Services are associated with a bid via this table
String description
static belongsTo = [ bid: Bid, item: Price ]
}
class Price { // The price of individual products and services the company offers
String description
Long value
static belongsTo = [ versionNumber: VersionControl]
}
class VersionControl {
/** So that when filling in the ItemList form for a bid, I can query for only
* prices with the correct version number
*/
String user
Long versionNumber
Date timestamp
static hasMany = [ bid: Bid, productOrService: Price ]
}
This example works fine, and illustrates what I want to do. I just don't know if it is the best way to address the problem and how well it will scale - I have around 20 tables containing different parameters who's versions I need to keep track of.
A bid will always be assigned the latest version of a pricing list, but the user must have the ability to be able to select a different version.
I should probably mention that prices will be updated in bulk, not individually, using a csv file provided by the accounting department. Each csv represents a new discreet price list version, not just as far as the database is concerned, but from an internal management perspective.
A similar philosophy will affect other tables in the DB such as exchange rates to use or geographical regions where the company operates.
The regularity with which new versions are released is also hard to predict which could make determining the endDate a problem.

There is no special Grails support for this goal, this is simly a 4th normal form. In your case it will be a header table for price entity and a subtable for value in time with limits:
class Price {
static hasMany = [ values: PriceValue ]
}
class PriceValue {
Number amount
Date validFrom
Date validTo
static belongsTo = [ price: Price ]
}

I believe ou should not extract Version into a separate entity, while your Price is clearly an Effectivity with strictly given time interval (I assume).
So I propose the following design:
class Product {
// whatever
}
class ProductPrice {
String description
BigDecimal value
DateTime startDate // or use JodaTime Interval
DateTime endDate
static belongsTo = Product
}
class Bid { // Each new customer bid is stored in this table
String bidName
DateTime bidDate // or use createdDate
static hasMany = [products: Product]
static belongsTo = [ Customer ]
BigDecimal getProductPrice(Product p) {
ProductPrice.where{
product = p && startDate >= bidDate && endDate < bidDate
}.find()
}
// or even
static transients = [ 'prices' ]
List<ProductPrice> getPrices() {
products.colect{ getProductPrice(it) }
// or even...
ProductPrice.where{
product = p &&
startDate >= bidDate &&
endDate < bidDate
}.list()
}
}

I would suggest using an oracle database and their "workspace manager" feature (I use it with grails and it works pretty nice) http://www.oracle.com/technetwork/database/enterprise-edition/index-087067.html
This would solve all the requirements you listed: if you "version enable" a table that gives you the capability to create workspaces of the current snapshot of data from the parent you are branching from. All these workspaces can make changes independently of each other and merge back into the main workspace when they are ready (and oracle simplifies the conflict resolution between them). However, not all tables have to be versioned such as your pricing tables so they will be managed regularly.
There are tons of other useful features but it sounds like it's basic functionalities would fit your bill. The only thing special you would have to do is keep track of the workspaces and their states as the application users checkout, merge, and resolve conflicts on your UI.

Related

How can I update or change cost price (standard price) in odoo v13 postgresql database?

I am trying to change the cost price of products in Odoov13 in postgresql database, can anyone please support me with an example or guide? The question is simple, there is a selling price and a cost price (standard price) on the products, I just try to change the cost price, not the selling price, but I don't know how to get to the table or column, the Only reference I have is that the value can be stored in property field, but I don't know how to access it.
SELECT * FROM ir_property WHERE name = 'standard_price';
Fini
The field standard_price is computed field without store=True So it can store the data into postgres database.
If you want to update the field value, You can make the server-action following step:
Goto Settings->Server Actions
Model : Product Template
Action To Do: Update the Record
Data to Write:
Field : Cost (product.template)
Evaluation Type: Value
Value: Add your value example, 112
make the Create Contextual Action
Goto Product template and refresh the page on the action you can find the created server action and execute.

football / soccer software design pattern

A basic question.
Think of football/soccer.
I thought about making a design pattern for it, but wanted to know if there is already one out there.
It goes as follwing:
I want to create a football player.
We have a gender. (Male and Female).
A gender have a Series Category (for example for young under 19, for young under 18 etc.).
That Series Category is placed in a region (or state whatever).
And that Region has its series' name (for example series 1, series 2, division 1 etc.).
For example, I want to make female, Senior, she plays in Birmingham, and is in the first division.
I want to map this into the database, but I wanted to follow a software design pattern, but I do not know if there is a software design pattern for this purpose.
My attempt is like this:
Gender
{
int GenderID
GenderType
}
SeriesCategory
{
int SeriesCategoryID
string SeriesCategoryName
int GenderID
}
Region
{
int RegionID
string RegionName
int SeriesCategoryID
}
Series
{
int SeriesID
string SeriesName
int RegionID
int SeriesCategoryID
}
I think you should design your database using normalization principles (read more here - http://www.studytonight.com/dbms/database-normalization.php )
Regarding software patterns - the are no exact patterns for your case. But use best practices and principles like SOLID. Mapping code entities to database ones and vise versa is responsibility of ORMs, which are existing in huge number of variations for different languages and requirements (SQL/NOSQL, code-first/database-first etc).
So for your exact case with footballers and teams I think DB normalization is all you required at the moment.
Why do you need all the attributes of "Series" separately. If that is not a necessity I would have created just a "Footballer" and a "League" objects. And probably one footballer can play in one league, but there can be many footballers in a league. Therefore there would be a many-to-one relation between "Footballer" and "League.
Footballer
{
int FootballerID
int age
GenderType
League
}
League
{
int LeagueID
String leagueName
String regionName
String categoryName
GenderType
}
So there is a many-to-one relation between FootballerID and LeagueID. First you can create a league without any footballers in it.Then, you can create a footballer with its age and gender, and then you can add this footballer to a league by checking their age and gender restrictions in the league category. A team object could also be nice though.

Many to Many Relationship in a Transactional System With Google Datastore/Python NDB

I am writting an application for a crop warehousing company, which purchases the harvested crop and stores it in one or more warehouses. Till now limitations of Google App Engine/Datastore was not posing problem to me. And I so deep into the project that it's very difficult to return.
I have to establish a many to many relationship between two Kinds which are transactional (means parent/ancestor queries) in nature. I am not sure what is the right approach to do this. This is the business logic:
Warehouse issues a purchase order for a specific quantity (PO). So we create an entity in PO Kind for each purchase order (PO).
Goods are received at the warehouse. So we create an entity in GRN Kind. (GRN=Goods Receiving Notes).
Here is many to many relationship.
One GRN may be required to complete one PO.
One GRN may be required to complete many POs.
Many GRNs may be required to complete one PO.
Many GRNs may be required to complete many POs.
This is a relevent snapshot of the code.
class Warehouse(ndb.Models):
name = ndb.TextProperty()
capacity = ndb.FloatProperty()
current_stock = ndb.FloatProperty()
class PurchaseOrder(ndb.Models):
quantity = ndb.FloatProperty()
remaining = ndb.FloatProperty()
is_complete = ndb.BooleanProperty()
grn = ndb.KeyProprty(repeated=True, kind=GRN)
class GRN(ndb.Models):
quantity = ndb.FloatProperty()
remaining = ndb.FloatProperty()
is_complete = ndb.BooleanProperty()
po = ndb.KeyProprty(repeated=True, kind=PurchaseOrder)
Entity Group Relationships
Warehouse -> GRN
Warehouse -> PO
To establish many - to - many relationship I hold all the related GRN Keys in a PO record and all related PO Keys in a GRN record. This is working fine for me.
But in case I have to edit a GRN or PO in the back date, then I am not able to handle the complication of cascaded changes which may impact other GRNs and POs.
Somewhere I read I should be using a third model to hold the many - to - many relationship, rather than storing the related keys. I am not able to visualize what that third table to should contain. *
I know my problem is very specific and I have not funished all the details. But just help me with the right approach for this kind of problem pattern. I will handle the rest. Or provide any link if this is already documented somewhere.
I would add a many-to-many relationship called GRNinstance that links a single GRN instance with a single PO:
class PurchaseOrder(ndb.Models):
quantity = ndb.FloatProperty()
remaining = ndb.FloatProperty()
is_complete = ndb.BooleanProperty()
class GRN(ndb.Models):
quantity = ndb.FloatProperty()
remaining = ndb.FloatProperty()
is_complete = ndb.BooleanProperty()
class GRNinstance(ndb.Models):
po = ndb.KeyProperty(kind=PurchaseOrder)
grn = ndb.KeyProperty(kind=GRN)
quantity = ndb.FloatProperty()
The sum of GRNinstance.quantity for a particular po should add up to PurchaseOrder.quantity, and the sum of GRNinstance.quantity for a particular grn should add up to GRN.quantity.
In fact, Dmitry's ComputedProperty could replace both PurchaseOrder.quantity and GRN.quantity (but that could be slow). Maybe is_complete could be a simple test:
is_complete = ndb.ComputedProperty(lambda self: self.remaining > 0)

Database design in website that sells tickets for events with Django

I'm working on a website that sells tickets for events. And I have the following design:
And the (simplified for posting) models:
class Event(models.Model):
name = models.CharField(max_lenght=20)
class Date(models.Model):
event_start = models.DateTimeField()
event = models.ForeignKey(Event)
class Ticket_Class(models.Model):
name = models.CharField(max_lenght=20)
price = models.IntegerField()
event = models.ForeignKey(Event)
How should I add a Ticket model? Because a Ticket is for an Event on a particular Date, so I would need to relate a ticket to the relationship between Event and Date
A Ticket_Class should also have a "max" field where is stored the maximum tickets available to sell for that particular Ticket_Class on a particular Date. E.g.: Event "Metallica" has Ticket_Class "Field" and Ticket_Class "VIP", both on three different dates. How would I access the number of remaining tickets for a Ticket_Class on a particular Date? Maybe counting how many Tickets are in the Ticket table corresponding to that Event on that Date.
I hope I made myself clear, english is not my first language. Feel free to ask any doubts
I think your design should be something like this:
class Event(models.Model):
name = models.CharField(max_lenght=20)
class Date(models.Model):
event_start = models.DateTimeField()
event_end= models.DateTimeField()
class Ticket_Class(models.Model):
name = models.CharField(max_lenght=20)
price = models.IntegerField()
type= models.CharField(max_lenght=20)
class EventTicketSell(models.Model):
event= models.ForeignKey(Event)
date= models.ForeignKey(Date)
ticket= models.ForeignKey(Ticket_Class)
max_sellable_tickets= models.IntegerField()
Reason for this design is that you can add a event to EventTicketSell class, then assign date and ticket with max sellable tickets.
for adding ticket/date/event:
event1= Event(name= "Lion King")
event1.save()
event2= Event(name= "Metallica")
event2.save()
vip_ticket= Ticket_Class(name='VIP', price= 100, type='VIP')
vip_ticket.save()
evening_show= Date(event_start='Date Object', event_end= 'Date Object') # Date Object is like datetime.datetime.now()
evening_show.save()
concert_ticket_sell= EventTicketSell(event=event1, ticket=vip_ticket, date= evening_show, max_sellable_ticket=500)
concert_ticket_sell.save()
movie_ticket_sell= EventTicketSell(event=event2, ticket=vip_ticket, date= evening_show, max_sellable_tickets=500)
movie_ticket_sell.save()
This design will keep objects reusable and flexible to modify. For example, if you want to change max_sellable_ticket then:
movie_ticket_sell= EventTicketSell.objects.filter(event__name='Lion King', date__event_start= datetime.datetime.now(), ticket__type= 'VIP')[0]
movie_ticket_sell.max_sellable_tickets -= form.cleaned_data['ticket_sold'] #for example we get sold count from form
movie_ticket_sell.save()
It seems like the event needs to have a ticket amount field to verify what the max tickets are. Then it should have a foreign key relationship with the ticket_class. In order to make sure you do not exceed the amount of tickets available then you would probably need to use something like the clean method to verify it does not exceed when associating a ticket to an event.
https://docs.djangoproject.com/en/1.5/ref/models/instances/#django.db.models.Model.clean
I'm just looking at this from a high level so maybe I'm missing something. I'm also unclear why you can't just have the date be a field in the event?

How do I easily keep records in a database linked together?

I've got a requirement that I believe must occur very frequently around the world. I have two records that are linked together and whenever a change is made to them a new pair of records is to be created and retain the same link.
The requirement I'm working on has to do with the insurance industry which requires me to deactivate the current insurance policies and re-activate them in a new row in order to show the history of changes made to the insurance policies. When they are re-created they still need to be linked together.
An example of how this process is intended to work from the view of rows in a database:
Insurance Id, Insurance Type, Master Insurance Id, Status
1, Auto Insurance, null, Active
2, Wind Screen Insurance, 1, Active
Note in the above how the link between these policies is denoted by the Master Insurance Id of the second row pointing the the Insurance Id of the first row.
In the code I am writing I am processing each of the policies one at a time so after the first step I have the following:
1, Auto Insurance, null, Inactive
2, Wind Screen Insurance, 1, Active
3, Auto Insurance, null, Active
When I process the second policy I get the following:
1, Auto Insurance, null, Inactive
2, Wind Screen Insurance, 1, Inactive
3, Auto Insurance, null, Active
4, Wind Screen Insurance, 1, Active //needs to be 3 not 1
You'll notice that when I create the new Window Insurance that since we copy the old row we end up with the Master Id insurance pointing to the inactive row.
In order to get around this, I have to keep track of the master insurance id of the previous policy that was processed which has led to the following code:
int masterInsuranceId = -1;
foreach(Policy policy in policyList)
{
//copy the old policy so the new policy has
//the same details as the old one
Policy newPolicy = policyManager.Copy(policy);
//if the new policy is not the master insurance store
//the master its new master insuance
if(newPolicy.MasterInsuranceId.HasValue)
{
newPolicy.MasterInsuranceId = masterInsuranceId;
}
//save the details of the new policy
policyManager.SavePolicy(newPolicy);
//record the master id so we can update the master id
//reference on the next policy
if(newPolicy.MasterInsuranceId == null)
{
masterInsuranceId = newPolicy.Id;
}
else
{
masterInsuranceId = -1;
}
//inactivate the current policy
policy.Status = Inactive;
policyManager.UpdatePolicy(policy);
}
Does anyone know how this can be simplified? What is the best way to ensure two records will remain linked to each other even as a history of the changes is recorded for each change made to the record?
What sort of database schema are you using? Usually, this is where relationship should be stored and I think this should be hanlded at the data processing level rather than code.
Here's a very simplified recommendation
insurance (< insurance_id >, name, description)
insurance_item(< item_id >, < insurance_id >, name, description)
insurance_item_details(< item_id >, < policy_id >, when_changed)
insurance__policy has a 1 to many relationship with insurance_item. An insurance__item has a one to many relationship with insurance_item_details. Each row in insurance__item__details represents a change in policy.
This way, a SQL can quick quickly retrieve the latest two items
SELECT FROM insurance_item_details, insurance_item, insurance where
insurance_item_details.item_id = insurance_item.item_id
AND insurance_item.insurance_id = insurance.insurance_id
ORDER BY when_changed
LIMIT 1
Or you can even retrieve the history.
(The SQL has not been tried)
So the idea is you don't duplicate insurance_item -- you have another table to store the elements that would be changed, and slap a timestamp with it represent that change as a relationship.
I'm not a SQL guru (unfortnately), but all you need to do is to insert into the insurance_item_details table, instead of making copies. From the way it looks, making copies like in your original example seems to violate 2NF, I think.
IF you had a bad code design and you needed to make a change would you refactor? THen why would you not consider refactoring a bad database design? This is something that is more ealisy handled in the database through good design.
If you are working in the insurance industry which is data intensive and you are not strong in database design and query skills, I would suggest you make it a priority to become so.
Thanks everyone who has provided answers. Unfortunately, due to conditions at work I'm unable to implement database changes and am stuck trying to make due with a coding solution.
After spending some time over the weekend on this problem I have come up with a solution that I believe simplifies the code a bit even though it is still nowhere near perfect.
I extracted the functionality out into a new method and pass in the master policy that I want the new policy linked to.
Policy Convert(Policy policy, Policy masterPolicy)
{
Policy newPolicy = policyManager.Copy(policy);
//link the policy to it's master policy
if(masterPolicy != null)
{
newPolicy.MasterPolicyId = masterPolicy.Id;
}
SavePolicy(newPolicy);
//inactivate the current policy
policy.Status = Inactive;
policyManager.UpdatePolicy(policy);
return newPolicy;
}
This allows me to then loop through all the policies and pass in the policy that needs to be linked as long as the policies are sorted in the correct order...which in my case is by start date and then by master policy id.
Policy newPolicy = null;
foreach(Policy policy in policyList)
{
Policy masterPolicy = policy.MasterPolicyId.HasValue ? newPolicy : null;
newPolicy = Convert(policy, masterPolicy);
}
When all is said and done, it isn't all that much less code but I believe it is much more understandable and it allows individual policies to be converted.

Resources