On 22/12/15 00:14, jamie hu wrote: > Thanks Alan. I was thinking about making a list of objects and search > through it, but wasn't sure if that was right way.
For small numbers of objects( aa few hundreds say) its the easiest option. > I wasn't sure instantiation needed when using database, It makes life easier but only instantiate the objects you need to work with. If doing bulk updates or just searching for specific data you can write SQL functions that work at database level. But remember the rule of OOD - objects do it to themselves. So you need to instantiate the objects to be able to call their methods. Sometimes a hybrid approach can work. Store the objects in a dict keyed by ID. Use SQL to identify the object you need then use the ID to fetch it from the dictionary if its already instantiated otherwise use an ID based init() method to fetch it from the database. That way the select only has to return an ID and the object instantiation fetches the specific data when you need it. Remember that any updates to instance data need to be written back to the database... The idea is usually to minimise the time any object lives in memory since that's when its most vulnerable to unrecorded changes and especially if more than one client or app is accessing the same data. > that's the way. So ORM libraries do this work (fetch data and return > instantiated objects) behind the scenes?? Yes, that's exactly why they are used. They hide the fact that there is a database there at all, it looks like you are just working with objects in memory. At least that's the theory, in practice there are usually some compromises! -- Alan G Author of the Learn to Program web site http://www.alan-g.me.uk/ http://www.amazon.com/author/alan_gauld Follow my photo-blog on Flickr at: http://www.flickr.com/photos/alangauldphotos _______________________________________________ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: https://mail.python.org/mailman/listinfo/tutor
