Develop Reference

Filtering with search-index

I want to implement a full-text-search for *.epub-Files. Therefore I forked the epub-full-text-search module (https://github.com/friedolinfoerder/epub-full-text-search).
I will have many ebooks to search through, so I want to have a way to only search in a specific ebook one at a time.
How could I do this with search-index. I coded a solution which allows to search in the fields filename (the unique filename of the epub) and body (the content of the chapters), but this doesn't feel like it's the right way to do this and the performance is also not ideal.
Here is an example how I do the search with search-index:
searchIndex.search({
query: [{
AND: [
{body: ['epub']},
{filename: ['accessible_epub_3']}
]
}]
});
Is there a better way to do this. Maybe with buckets, categories and filters?
Thanks for your help!

Search-index, which epub-full-text-search is based on, gives one search result back for each document/item that has a match for any given query. My guess is that you would like to know where in the epub-file you get a hit. If a certain paragraph is a good enough search result item, I would index paragraphs. Each paragraph would have a unique book-key as a filter, and maybe a reference to where it is in the epub-file (page/percentage/etc).
Disclaimer: I'm working on the search-index project.

Parse - How do I query a Class and include another that points to it?

I have two classes - _User and Car. A _User will have a low/limited number of Cars that they own. Each Car has only ONE owner and thus an "owner" column that is a to the _User. When I got to the user's page, I want to see their _User info and all of their Cars. I would like to make one call, in Cloud Code if necessary.
Here is where I get confused. There are 3 ways I could do this -
In _User have a relationship column called "cars" that points to each individual Car. If so, how come I can't use the "include(cars)" function on a relation to include the Cars' data in my query?!!
_User.cars = relationship, Car.owner = _User(pointer)
Query the _User, and then query all Cars with (owner == _User.objectId) separately. This is two queries though.
_User.cars = null, Car.owner = _User(pointer)
In _User have a array of pointers column called "cars". Manually inject pointers to cars upon car creation. When querying the user I would use "include(cars)".
_User.cars = [Car(pointer)], Car.owner = _User(pointer)
What is your recommended way to do this and why? Which one is the fastest? The documentation just leaves me further confused.

I recommend you the 3rd option, and yes, you can ask to include an array. You even don't need to "manually inject" the pointers, you just need to add the objects into the array and they'll automatically be converted into pointers.

You've got the right ideas. Just to clarify them a bit:
A relation. User can have a relation column called cars. To get from user to car, there's a user query and then second query like user.relation("cars").query, on which you would .find().
What you might call a belongs_to pointer in Car. To get from user to car you'd have a query to get your user and you create a carQuery like carQuery.equalTo("user", user)
An array of pointers. For small-sized collections, this is superior to the relation, because you can aggressively load cars when querying user by saying include("cars") on a user query. Not sure if there's a second query under the covers - probably not if parse (mongo) is storing these as embedded.
But I wouldn't get too tied up over one or two queries. Using the promise forms of find() will keep your code nice and tidy. There probably is a small speed advantage to the array technique, which is good while the collection size is small (<100 is my rule of thumb).
It's easy to google (or I'll add here if you have a specific question) code examples for maintaining the relations and for getting from user->car or from car->user for each approach.

What is the Python best practice concerning dicts vs objects for simple key-value storage?

After some time programming in Javascript I have grown a little fond of the duality there between objects and associative arrays (dictionaries):
//Javascript
var stuff = { a: 17, b: 42 };
stuff.a; //direct access (good sugar for basic use)
stuff['a']; //key based access (good for flexibility and for foreach loops)
In python there are basically two ways to do this kind of thing (as far as I know)
Dictionaries:
stuff = { 'a': 17, 'b':42 };
# no direct access :(
stuff['a'] #key based access
or Objects:
#use a dummy class since instantiating object does not let me set things
class O(object):
pass
stuff = O()
stuff.a = 17
stuff.a = 42
stuff.a #direct access :)
getattr(stuff, 'a') #key based access
edit: Some responses also mention namedtuples as a buitin way to create lighweight classes for immutable objects.
So my questions are:
Are there any established best-practices regarding whether I should use dicts or objects for storing simple, method-less key-value pairs?
I can imagine there are many ways to create little helper classes to make the object approach less ugly (for example, something that receives a dict on the constructor and then overrides __getattribute__). Is it a good idea or am I over-thinking it?
If this is a good thing to do, what would be the nicest approach? Also, would there be any good Python projects using said approach that I might take inspiration from?

Not sure about "established best practices", but what I do is:
If the value types are homogenous – i.e. all values in the mappings are numbers, use a dict.
If the values are heterogenous, and if the mapping always has a given more or less constant set of keys, use an object. (Preferrably use an actual class, since this smells a lot like a data type.)
If the values are heterogenous, but the keys in the mapping change, flip a coin. I'm not sure how often this pattern comes up with Python, dictionaries like this notably appear in Javascript to "fake" functions with keyword arguments. Python already has those, and **kwargs is a dict, so I'd go with dicts.
Or to put it another way, represent instances of data types with objects. Represent ad-hoc or temporary mappings with dicts. Swallow having to use the ['key'] syntax – making Python feel like Javascript just feels forced to me.

This would be how I decide between a dict and an object for storing simple, method-less key-value pairs:
Do I need to iterate over my key-value pairs?
Yes: use a dict
No: go to 2.
How many keys am I going to have?
A lot: use a dict
A few: go to 3.
Are the key names important?
No: use a dict
Yes: go to 4.
Do I wish to set in stone once and forever this important key names?
No: use a dict
Yes: use an object
It may also be interesting to tale a look at the difference shown by dis:
>>> def dictf(d):
... d['apple'] = 'red'
... return d['apple']
...
>>> def objf(ob):
... ob.apple = 'red'
... return ob.apple
...
>>> dis.dis(dictf)
2 0 LOAD_CONST 1 ('red')
3 LOAD_FAST 0 (d)
6 LOAD_CONST 2 ('apple')
9 STORE_SUBSCR
3 10 LOAD_FAST 0 (d)
13 LOAD_CONST 2 ('apple')
16 BINARY_SUBSCR
17 RETURN_VALUE
>>> dis.dis(objf)
2 0 LOAD_CONST 1 ('red')
3 LOAD_FAST 0 (ob)
6 STORE_ATTR 0 (apple)
3 9 LOAD_FAST 0 (ob)
12 LOAD_ATTR 0 (apple)
15 RETURN_VALUE

Well, if the keys are known ahead of time (or actually, even not, really), you can use named tuples, which are basically easily-created objects with whatever fields you choose. The main constraint is that you have to know all of the keys at the time you create the tuple class, and they are immutable (but you can get an updated copy).
http://docs.python.org/library/collections.html#collections.namedtuple
In addition, you could almost certainly create a class that allows you to create properties dynamically.

Well, the two approaches are closely related! When you do
stuff.a
you're really accessing
stulff.__dict__['a']
Similarly, you can subclass dict to make __getattr__ return the same as __getitem__ and so stuff.a will also work for your dict subclass.
The object approach is often convenient and useful when you know that the keys in your mapping will all be simple strings that are valid Python identifiers. If you have more complex keys, then you need a "real" mapping.
You should of course also use objects when you need more than a simple mapping. This "more" would normally be extra state or extra computations on the returned values.
You should also consider how others will use your stuff objects. If they know it's a simple dict, then they also know that they can call stuff.update(other_stuff) etc. That's not so clear if you give them back an object. Basically: if you think they need to manipulate the keys and values of your stuff like a normal dict, then you should probably make it a dict.
As for the most "pythonic" way to do this, then I can only say that I've seen libraries use both approaches:
The BeautifulSoup library parses HTML and hands you back some very dynamic objects where both attribute and item access have special meanings.
They could have chosen to give back dict objects instead, but there there is a lot of extra state associated with each object and so it makes perfect sense to use a real class.
There are of course also lots of libraries that simply give back normal dict objects — they are the bread and butter of many Python programs.

Transitioning Between Record Types in Salesforce

Salesforce allows you to extend Object definitions by using Record Types. Is there a quick and easy way to allow users to transition groups of Objects from one Record Type to another? In my case, I will be keeping track of students as they progress through the undergraduate student life cycle from applicant to alumnus. It makes sense to me to keep track of the different phases of the student life cycle as Record Types so that I can create custom interfaces/viewing permissions/business logic for each phase. I was hoping to be able to create a custom button or link to do this as per this example from Salesforce:
Salesforce: Getting Started With Buttons and Links.
However I have had no luck querying the RecordType object using the Ajax toolkit to find out which RecordTypeId I will need to update the Object to. (I am rather new to JavaScript so it may simply be my inexperience that's getting in the way. I would be happy to post code samples of what I've tried so far if anyone asks.)
On the IdeaExchange someone mentioned that you can just include the RecordType field in the object's custom layout page (IdeaExchange: Provide a Means of Changing Record Types), but this does not seem like a reasonable solution for managing hundreds of students.
Using a workflow or a trigger does not seem like a reasonable solution either because those apparently require you to update a record or create a new one. Students should be able to transition at any time, independently of updates or new additions.
SO likes it when you mention other things that your issue could pertain to, but I think those areas are pretty self-explanatory here; this issue is relevant any time you might like to programatically transition between different record types.

What you want is probably not the RecordType object itself, but rather the RecordTypeId field on your object you are using to track students which looks up to that RecordType object. For example, to find the record type of a given student, the SOQL would look like:
SELECT RecordTypeId FROM Student__c WHERE Id = {some id}
and then if you wanted to update the record, you could change the value of the RecordTypeId like this:
var student = new sforce.SObject("Student__c");
student.Id = '{some id}';
student.RecordTypeId = '{new record type id}';
result = sforce.connection.update([student]);
To find the eligible RecordTypeIds for a given object type, you can either query the RecordType object and filter on the SObjectType column, or just call describeSObject(Student__c) and inspect the RecordTypeInfos node in the result.

How to get a list of pages if site having two pages-with same name?

for example
http://www.sitename.com/section1/pagename.aspx
http://www.sitename.com/section2/pagename.aspx
I need quick report only for pages which has same name. like "pagename.html" in example.

crawl your site, reverse the found URLs and sort?

If this is a Sitecore site as I'm led to believe, could you not just go into the Content Editor and search for the name you're looking for? Anything with the item name of "pagename", for example, will have a URL ending with "pagename.aspx" in your standard Sitecore install. Just make sure you're looking at the actual item name and not the display name, as they can be quite different at times depending on how you've got the URL's set up.

I would write a quick utility program to just traverse the content tree programmatically, saving the names to a dictionary... when you hit an item that is already in the dictionary, you've got a name collision.

One thing you might consider is writing a filter (I think that is what it is called) for this
http://trac.sitecore.net/AdvancedSystemReporter
That would allow you to have a nice interface in Sitecore for viewing duplicate item names.

How big is your database, and how is your LINQ to Objects? Theoretically you could write a LINQ query against Database.Items that looks for items with the same name that descend from the same site branch of your content tree. This could be very memory intensive if your master DB is large, but would not be difficult to code.
Edit -- if you can loop over all your site items, you could do something like this (untested):
var items = siteItem.Axes.GetDescendants();
var dupes = from item in items
join item2 in items on item.Name equals item2.Name
where item.ID != item2.ID
select item;