Customer model capabilities implied by tariff options

classic Classic list List threaded Threaded
47 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Re: Customer model implementation

achryso
I have downloaded the new powertac-common plugin  and tried to see how things work.

I have to say that I have some objections as far as the database relationships are concerned. I think that a lot of changes must be done to have correct dependencies and create a database in the 3rd Normal Form as it should be.

I tried to look in the Tariff, TariffSubscription, TariffSpecification etc and I have to say there is a lot of information redundancy. I would like to take a better look and suggest some things if I might.

If another version is to be uploaded soon, I would like to know so that I don't change my models until all the details are in place.

Thank you in advance.
Reply | Threaded
Open this post in threaded view
|

Re: Customer model implementation

grampajohn
Administrator
On 02/16/2011 07:48 AM, achryso [via Power TAC Developers] wrote:
> I have downloaded the new powertac-common plugin and tried to see how
> things work.
>
> I have to say that I have some objections as far as the database
> relationships are concerned. I think that a lot of changes must be done
> to have correct dependencies and create a database in the 3rd Normal
> Form as it should be.

I have been treating the problem as a responsibility assignment problem
rather than a data modeling problem. As a result, many of the
"properties" of Tariff are delegated to TariffSpecification, but they
are marked as "transients" which means they are NOT in the database.
This is intended to simplify customer coding, so that a customer can
interact with the Tariff for evaluation purposes, and with
TariffSubscription once it has subscribed, and not have to pull out the
underlying TariffSpecification and its Rates. I see TariffSpecification
with its Rates and HourlyCharge instances as serializable message
content between broker and server. Also, Tariff does a transformation on
the Rates to simplify determination of the cost of power at any
particular point in time. That transformation is indeed stored in the
database, and it is redundant, strictly speaking. However, I judge this
redundancy to be preferable to forcing customers to do complex queries
against TariffSpecification and Rate types.

I welcome your input on how this could be done better.

>
> I tried to look in the Tariff, TariffSubscription, TariffSpecification
> etc and I have to say there is a lot of information redundancy. I would
> like to take a better look and suggest some things if I might.

Yes, of course.

>
> If another version is to be uploaded soon, I would like to know so that
> I don't change my models until all the details are in place.

For now, I have finished what I intended to do on Tariff and related
parts, with the possible exception of #88, which is a broker function
rather than a customer function. The only remaining task on issue #73
that I know of is to implement tariff revocation, which I think is a
relatively low-priority feature for the moment. I'm now focusing on
issues 100, 102, and 103. I'm also doing #104 incrementally, and I would
very much like to work with you on #105.

Your comments and criticisms are always welcome.

John
Reply | Threaded
Open this post in threaded view
|

Re: Customer model implementation

achryso
This is a relationships schema that I created for the tables in question for customers.

The dashed connections are the ones that are not needed but can be added with caution on update, delete etc.



I would like to hear your opinion on this. For your ease, I could write my notes down on an document in order to discuss over it.

Thank you in advance.

Anthony.
Reply | Threaded
Open this post in threaded view
|

Re: Customer model implementation

grampajohn
Administrator
I agree that the dashed connections are not needed, and I'm in the process of eliminating them. In fact, Competition is a singleton within the scope of the simulation, so it does not need any relationships. I might leave the Broker relationship there, but it's not really needed.

I assume the box you have labeled "Tariff" is actually "TariffSpecification", right? It should be. Tariff is a "wrapper" type, intended to simplify access to TariffSpecification and its associated Rates, to keep track of realized-price, and to manage TariffSubscription instances.

Does this help?

John
Reply | Threaded
Open this post in threaded view
|

Re: Customer model implementation

achryso
Yes, indeed, if the Tariff is used as a wrapper, then the correct should be TariffSpecification.

The thing is if the relationship diagram I presented is followed, we will have only 1 to many relationships, making it easier to create the objects and their relationships.

In the latest version of the common plugin, there are still duplicates of some of the variables in certain classes, for example in TariffSubscription. Also, some of the variables (most of them are the BelongTo variables) of the classes must be nullable so that they can be inserted later on and not on object creation. For example in TariffTransactions where we would have the timeslot and the subscription variable in BelongsTo relationship, the timeslot variable should be nullable in order to utilize correctly timeslot.addToTariffTx command. Maybe there is another way, but I don't seem to find it.  

If you think there is a need for Many to Many Relationships for some of the tables, I would like to hear how you expect things to work.

I have created an small example utilizing all the available tables with my code, I will try to upload it soon. The thing is that I made some changes in the common plugin code in order for them to work correctly.

Anthony
Reply | Threaded
Open this post in threaded view
|

Re: Customer model implementation

grampajohn
Administrator
On 02/19/2011 03:32 PM, achryso [via Power TAC Developers] wrote:
> Yes, indeed, if the Tariff is used as a wrapper, then the correct should
> be TariffSpecification.
>
> The thing is if the relationship diagram I presented is followed, we
> will have only 1 to many relationships, making it easier to create the
> objects and their relationships.

We should try to keep it that way.

>
> In the latest version of the common plugin, there are still duplicates
> of some of the variables in certain classes, for example in
> TariffSubscription.

I'm looking at TariffSubscription, and I do not see the duplicate data,
although the relationship with CustomerInfo should be a belongsTo
relationship. Could you please be a little more specific?

> Also, some of the variables (most of them are the
> BelongTo variables) of the classes must be nullable so that they can be
> inserted later on and not on object creation. For example in
> TariffTransactions where we would have the timeslot and the subscription
> variable in BelongsTo relationship, the timeslot variable should be
> nullable in order to utilize correctly timeslot.addToTariffTx command.
> Maybe there is another way, but I don't seem to find it.

I'm still learning the subtleties of Grails constraints, so I'll take
your advice on this.

>
> If you think there is a need for Many to Many Relationships for some of
> the tables, I would like to hear how you expect things to work.

I have no examples of many-to-many relationships, and I agree we should
avoid them if possible.

> I have created an small example utilizing all the available tables with
> my code, I will try to upload it soon. The thing is that I made some
> changes in the common plugin code in order for them to work correctly.

If you want to share an example without changing the "main" version,
then you can push it on a branch. Nobody is using the tariff-dev branch
right now, as far as I know.  I am using the domainclass-updates branch
for the next few days.

Thanks!

John
Reply | Threaded
Open this post in threaded view
|

Re: Customer model implementation

achryso
I have forked the common plugin in my account and made the changes in the branch tariff-dev in order not to change the real plugin. I have followed the relationships of the schema I made.

I also updated my Consumer-Grails code (it's not a plugin it's a normal program since now) with the little program I mentioned before. So if you want to see my code and try it out you can by downloaded the two repositories and run the application.

Any note over it would be welcome, whenever you can of course. I will check out the whole procedure now and how we can design the classes in the common plugin.

Thank you in advance

Anthony
123