Yo estoy igual que tú, a la espera de que salga la semana 4.
Por cierto, alguien sabe cuántas semanas son?
A ver si me podéis solucionar una duda. Pongo como ejemplo la colección de students del curso developers de esta semana.
Si yo quisiera hacer una consulta para mostrar todos los alumnos que tengan nota en un tipo concreto (examen, tarea, etc.), ¿como haría para que en esos resultados solo me mostrase la nota del tipo que he seleccionado? Es decir, yo quiero que me muestre el nombre y SOLO las notas de exámenes, teniendo en cuenta que estas son un documento dentro de un array.
db.students.find({'notas.tipo':'examen'},{'nombre':1,????})El resultado que querría sería así:
{'nombre':'Pepe', 'notas':[{'tipo':'examen','nota':9}]}#123 Pues si funciona, muchas gracias 
. Estaba enredando con consultas y me entro la duda, por mas que buscaba no veía como hacerlo y me estaba inventando unas movidas muy raras para algo tan simple xD.
Efectivamente solo con el $ muestra también el tipo ^.
#122, nunca lo he probado y no tengo aquí la base de datos instalada, así que lo que te voy a decir lo mismo no funciona, pero prueba con esto:
db.students.find({'notas.tipo': 'examen'}, {'nombre': 1, 'notas.$.nota': 1})Básicamente el operador $ en esa situación lo que significa es "la posición del array notas donde se cumplió la condición anterior ('notas.tipo': 'examen' )". Aún así, el resultado no saldría exactamente como tú pides (no se mostraría que el tipo es examen, solamente se mostraría la nota). Supongo que si lo anterior funciona, para que se muestre también el tipo quizá bastaría con cambiar:
'notas.$.nota'por:
'notas.$'Pero ya te digo, igual me estoy equivocando, porque no puedo probarlo ahora mismo.
¡Salu2!
Pues ni idea, pero no debe de quedar mucho, ya que yo entrando con el tiempo justo para terminar los ejercicios de la segunda semana y habiendo terminado los de la tercera tengo 37.5% sobre 50% de la parte de ejercicios, supongo que debe quedar otra semana más (pero tampoco te fíes mucho, solo son suposiciones)
Saludos.
Me ha vuelto a pasar lo del mágico error 500.
Hice esta tarde los ejercicios a falta de hacer el validate y meter la solución. He cambiado de pc y resulta que en este no me pilla algunas páginas, me salta error 500 al entrar a la página principal y a las páginas de los post. Las demás funcionan todas (login, crear entrada, etc.). La semana pasada lo solucione ejecutando el archivo desde el directorio en vez de llamarlo con el path pero hoy ni con esas.
¿Alguna idea?
Tengo una duda en el anunciado..:/
"Write a program in the language of your choice that will remove the lowest homework score for each student. Since there is a single document for each student containing an array of scores, you will need to update the scores array and remove the homework"
Cuando dice " lowest homework",se refiere a los de han suspendido? es que no entiendo exatamente con las menores notas
no me asustéis que el de Dev se supone que tiene que estar el 19 y yo lo estoy dejando. estoy en lo cierto o se me ha ido la pinza?
¿algún buen compañero de clase me pasa las soluciones del m101 (dev) para la week3?
Voy a intentar sacarlo, pero voy justo de tiempo :S
Thanks in advance!
1h y media después de googlear mucho y procrastinar más, he terminado el hw3.1
Mañana el resto.
Cuando dicen día 19 de Noviembre 23:00 EST 2012 ¿qué hora es en Españistán? gracias !
#131 acabo de sacar el 3.2 hace unos minutos. Es ese, efectivamente. Estoy con el 3.3. Tengo tiempo, tranqui. Te lo agradezco igualmente. No lo quería en plan gorrón. Me estoy currando el curso, pero iba justo de tiempo. Ya se con quien puedo contar en caso de retraso. Cuenta también conmigo si te hace falta 
Hay que reconocer que el 3.2 era para mi sobrino xD. Lo chungo es el 3.1
¿Quieres el 3.1? ¿Lo sacaste? Me gustaría comparar algoritmo. Yo lo he hecho con un método algo distinto al que aconsejaban.
y el del 3.3: dhfr48nf89jk093f9kj0d2d xDDDD
Edit: Thx! Lo mío es una ñapa total por no haber conseguido ordenar la consulta. De ahí que he guardado las dos homework y he tenido que comparar.
na, que no hay manera con el 3.1
y eso que tambien he probado con vuestro script.
ya he submiteado 2 de 3, ahora tengo miedo xD
#135 pero has cargado la base de datos que trae el ejercicio? xD
Si la has cargado, mi script debería de funcionar ok. Como decía Larrañaga: "Yo lo hishe" xDDDD
Ninja edit. Ya no hay problema ninguno. 
#138 Hombre, yo por lo menos lo hago para aprender y enterarme de algo. Somos ya todos mayorcitos para andar haciendo tramas sin sentido xD
ya está, se ve que lo estaba pegando mal, habia un caracter al final invisible xD
por cierto, se supone que a todos nos tiene que dar la misma solucion no? siendo así, no habrán miles de sitios con las respuestas ya hechas? y no le bajaría la caché al curso si así fuera?
#138 Yo creo que no,pero vaya si encuentras alguna web con las respuestas dimelo xD que cuando me canso iria bien una ayuda xD
Juraría que he hecho bien el 3.1, al menos comprobando estudiante por estudiante, le he quitado correctamente a todos la nota más baja.
El tema es que cuando he puesto la id de estudiante que me daba la consulta estaba mal, pero por más que miro todos los estudiantes se han procesado bien.
¿A alguien más le ha pasado?
A mi la solución me sale
Aquí mi código:
import pymongo
import sys
from pymongo import Connection
connection = Connection('localhost',27017)
db = connection.school
students = db.students
estudiantes = students.find()
for estudiante in estudiantes:
nota_min = 999
for nota in estudiante['scores']:
if(nota['score']<nota_min and nota['type']=='homework'):
nota_min = nota['score']
students.update({'_id':estudiante['_id']},{'$pull':{'scores':{'score':nota_min}}})EDIT: Vale me acabo de dar cuenta de que sólo hay que borrar los de tipo "homework"
EDIT2: #143 Sí, tan sencillo como añadir el and. Esto me pasa por no leer bien los enunciados xD
#134: La virgen o_O
#146: No, si lo mío no te creas que es gran cosa, pero fue abrir el spoiler y ver semejante cantidad de código, que me impresionó xD
#145 No tengo necesidad de excusarme. No tengo ni zorra de idea y menos del driver pymongo. Con lo cual voy tirando código hasta que funciona aunque el algoritmo sea una pena y nada optimizado. La cuestión es sacar el ejercicio. Estoy totalmente de acuerdo que el código es una basura. Hay cosas en las que emplear mejor el tiempo
Chavales, a ver si me podéis echar una mano. Un colega y yo tenemos que hacer una sencilla API REST para una app android, y queríamos guardar los datos en mongodb (por aquello de aprender).
Os comento rápidamente el modelo de datos:
Hasta aquí lo tenía bastante claro, una collección de documentos "Historia", donde guardas todos los datos y, luego, un array de eventos dentro. La cosa es que además tenemos que mantener varios idiomas, entonces ya tenemos más dudas.
La aproximación inicial era mantener, como antes, una collection de documentos Historia y, luego, todos los datos que dependan del idioma, tenerlos dentro de un array de idiomas, de forma que para una historia tendríamos algo así:
history = {"_id": 1,
"languages": ["en": {
"name": "name",
"desc": "desc",
"city": city,
"events" : [{"order":1,
"coordinates": {"lat": 1.1, "lon": 1.2},
"precission": 2,
"hint": "blabla",
"question": "what the fuck, maaan?",
"success_message": "Yeah!"},
{"order":2,
"coordinates": {"lat": 1.1, "lon": 1.2},
"precission": 2,
"hint": "blabla",
"question": "what the fuck, maaan?",
"success_message": "Yeah!"}]
}, "es": { lomismoperoencastellano}
}
(Los datos de los eventos están repetidos, pero creo que se entiende. Este esquema no me convence nada, alguna idea?
#148: Algo así como {question : [{es: "Cuántos años tienes"?}, {en: "How old are you?"}]}. No es mala idea, y me convence más que la mía pero aún así no del todo.
Fuck noSQL xDD
#147 y si cada elemento que puede tener varios idiomas es un diccionario de
{'idioma': 'blablaba',
'idioma2': 'bliblibli',
... }
?
#147 a mí el planteamiento que has hecho me parece correcto. Como bien comentan en el curso, el patrón de acceso es importantísimo en mongo a diferencia de un esquema relacional en el que más o menos cumpliendo las formas normales se tienen un patrón genérico.
En el caso que planteas lo primero es la historia, obviamente. Y luego me parece un acierto que el siguiente nodo del "árbol" sea el idioma. ¿Por qué? Porque quizás dentro de las colecciones de eventos y subcolecciones que pueda tener en un futuro, van a existir literales a porrón que tendrán que estar en un array o en una colección. Con lo cual creo que hay dos opciones:
1) Tal como lo has planteado.
Ventajas: El patrón de acceso es igual de simple para cada idioma, sólo hay que filtrar por historia e idioma y el resto igual. Es más escalable porque no le afecta las colecciones de nivel más bajo en el esquema que pudieran surgir con literales a traducir. Por tanto, en los diferentes accesos no habría que estar teniendo en cuenta el idioma constantemente en su correspondiente colección o array.
Desventajas: Se duplica todo el contenido del resto de información que no necesita ser traducida. Si aceptamos esto como algo no crítico (no tiene pinta de que vayan a existir millones de historias...), yo me quedo con la este planteamiento por su simplicidad de acceso.
2) Bajando de nivel en el árbol el idioma cuando le haga falta.
Ventajas: No se duplica información en los nodos raíz y la información está más normalizada en este sentido. Cualquier cambio en campos que no sean literales se producirán con filtro de la historia en cuestión sin tener que repetir por cada idioma la consulta/actualización.
Desventajas: Si en las colecciones inferiores de la jerarquía hay numerosos sitios distintos con literales, el acceso será más complicado teniendo que recorrer o filtrar constantemente colecciones o arrays de idiomas en múltiples nodos.
En resumen, la opción (1) es más simple a la par que vaga y perra xD. Pero si no hay mucha información, casi mejor.
La opción (2) es más académica pero el noSQL está para olvidarse de la duplicidad de datos y demás obsesiones del modelo relacional. Si se tuviera muy claro que el esquema no va a crecer, quizás sería la mejor opción. Pero hay que prepararse ante imprevistos. Como tengas que estar constantemente en nuevas colecciones que estar metiendo arrays con idiomas para cualquier literal... vaya aburrimiento de vida xD
Solución mixta:
Nodo 1: Historia
Luego el resto de elementos y uno de ellos es un array de literales donde por idioma metes todos ellos y los que te van haciendo falta. Pero todos juntitos, nada de repartirlos por otros nodos que se rompen el invento.
#147 #149 yo lo haría como comento en #148 por una simple razón: los documentos se guardan completos en disco, da igual que pongas el idioma en la raíz o en las hojas que te vas a comer el documento entero.
Sin embargo los metadatos no tienen mucho sentido por-idioma. Cuando tengas que filtrar por esos metadatos... ¿vas a filtrar en el array de idiomas completo? Un auténtico desperdicio de CPU y memoria, donde Mongo se resentirá más.
Los seeks en disco son CAROS porque va a haber mucho caché-miss.
Si hay MUCHO análisis de metadatos lo que quizá tendría sentido es hacer una colleción history con los metadatos y luego un history.en, history.es, etc. Pero esto no tiene sentido si casi siempre que accedasa history vayas a tirar de algún idioma (te comerás casi siempres dos accesos... LEEEEEEENTO.)
