There are two different "major" problems in that one example. The first is the technical issue of how to deal with data structure changes. The second is the business issue of scope change management.
Dealing with the data structure changes can be tricky, but it is very doable. I would tag every single entity in your datastore with a "model version" property. When you adjust the "Company" model bump it up to revision "2." On the next change to the Company model bump it up to 3 and so on. That will let you write logic capable of migrating the data structures in a very clean way. Large changes may need done in phases. In your case you are talking about possibly changing the access control to a kind. You know that is a possibility so I would just keep it in mind during the initial design phases. The technical part is not really different from any other system. If you make schema changes you might need to migrate data. The second problem is a business problem. Write a design spec with enough details for you to discuss these issues with the client, but not so many insignificant details the client will/can not understand it. Review it with them, and discuss these type of "known" issues. You may want to specifically note these types of things on the document. State it clearly: Sites will be tied to Users, not Companies. Make them sign it. In six months if they want to change it you can handle it as a separate project or as an "official" change request. Robert On Mon, Sep 6, 2010 at 15:47, nacho <[email protected]> wrote: > For example, a stupid but probably example. > > My application will let the users admin different sites. So a User can > have many Sites. Ok, perfect. > > My client sayd that the User is the owner of the Sites. Ok, perfect. > > But in real life, the User of my application is an employee of a > company. So, could it be that in a company that is separated in > sectors, many people would like to admin a Site in my application. So, > in this case, the model changes and a Site is owned by a Company and > the Users belongs to a Company. And different Users can have different > Roles to admin a Site that is owned by the user's Company. > > If i make the model based on what is asking now my client (many Sites > owned by a User) and then, in 6 months, my client realizes that wants > to change the application a do what i say (a User belongs to a > Company, and a Company can have many Sites, and the users have Roles > to admin the Sites) i think that with the Datastore i will pull out > the hair of my head to make a change so big to the model. Or don't? > > > But in really a User of my site will be an employee of a Company > > On 6 sep, 13:58, Tim Hoffman <[email protected]> wrote: >> Hi >> >> You might like to say if you are using python or java, that way >> examples can be relevent to your choice. >> >> >> >> > DOUBT 1: What happens, if i make a change to the User class and, for >> > example, i add to the class the property sex (String). Then i deploy >> > my app again in the appengine. >> >> > Now i create a new user with this values username = "mcculloch", >> > password = "mc123" and sex = "M" and persist the user. >> >> > I think that if i make the query to get all the useri will get the 2 >> > users, and the property sex to the user "ian" will be null. Is that >> > correct? >> >> Yes. >> >> >> >> > DOUBT 2: Now i realize that i don't want to store the sex of the user, >> > and also i think that i don't want the id property as an integer. Now >> > i want that the username will be the key of the class, so i remove the >> > id property and add the annotation to make the username property the >> > Primary Key of the entity. >> >> > Then i deploy the app on appengine, create a new user with this >> > values: username = "eric", password = "eric123". >> >> > What does happen now i query all the users, will i get the two users? >> >> Ok a bunch of stuff going on here. >> >> You refer to the primary key, do you mean as per SQL or some aspect of >> a java api. >> In the underlying datastore terms the key of entity once created is >> fixed. >> >> You would have to copy the original entity and delete the old one to >> change the key. >> >> As to the sex property. (I will start using python behaviour) you can >> drop the sex property definition from the >> entity but the value assigned to the Sex property will still exist in >> entities that had the value set. >> >> If you change the type of a property then you will need to fetch the >> old entity and update the value of the property to the type the model >> expects. This may require you to manipulate the underlying raw >> datastore entity or create a transition class to help you migrate the >> schema (i prefer the former). >> if not you will get errors when you retrieve entities with a mis- >> matched entity definition. >> >> If you fetch all uses User.all().fetch(n) you will get all users added >> assuming you have fixed above. >> >> > DOUBT 3: Let's say that i realize that i really need the sex property >> > for the users, so i add again the sex property to the User class and >> > deploy again to the datastore. >> >> > If i query for all the users? What datastore will return to me? All >> > the users? Only those that the sex is not null? >> >> All users will be returned, and some will still have a value for sex. >> You can't do a not null query unless you have actually stored None >> (python) in a property. (More specifically you can't query for >> entities that have not had a property value set). >> >> >> >> > DOUBT 4: Finally, what happens if i want to have 2 enviroments of my >> > app? I have to create 2 apps on appengine? If this is the way, let's >> > supose that in my production enviroment i have a lot of data and i >> > want to make a copy of that data to my testing app so i can make >> > testing with good data. Can i copy that data from one app to another? >> > How could i? >> >> Seehttp://code.google.com/appengine/docs/python/tools/uploadingdata.html >> >> T > > -- > You received this message because you are subscribed to the Google Groups > "Google App Engine" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/google-appengine?hl=en. > > -- You received this message because you are subscribed to the Google Groups "Google App Engine" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en.
