4 ms·

>And I would appreciate a way to define schema Use mongoose! >On the other hand, I do miss JOINs when I need them (though we solved that on app level). How y

by ttty 12y ago

>And I would appreciate a way to define schema Use mongoose! >On the other hand, I do miss JOINs when I need them (though we solved that on app level). How you do that? (maybe is different than me) What about transactions?

annnnd 12y ago
>Use mongoose! We don't use node.js. Also, we have app-level schema, but enforcing should (IMHO) be done on DB level so as to avoid any chance of invalid data. Joins: easy, we specify which fields are connected (on app level), then fetching goes to connected collections and fetches data from there too. Not ideal, but it works. We made a similar solution for foreign keys. Transactions: no need for any further guarantees. Our system mostly works on a single record at a time in all critical components. If this is not possible, we have app-level locking to avoid conflicts. No issues or wishes here.
- avasdvasdv 12y ago
  > If this is not possible, we have app-level locking to avoid conflicts. app-level locking is a recipe for disaster if data matters and more than 1 process/user/client/etc can access your data. if the data doesn't matter then I guess you can do whatever you want. web "developers" have a bad reputation for a reason. so many amateurs amongst web developers...
  - annnnd 12y ago
    I will assume the last part is just a generic statement and is not directed towards me. You are a Java dev I presume? As for app-level locking, I am talking about sacrificing performance, not safety. We just make sure that some piece of code runs exactly once. Since the need for this is very rare and the places are not performance critical, we can live with that. So no, we have no need for additional transactional guarantees on DB level.
    - avasdvasdv 12y ago
      > I will assume the last part is just a generic statement and is not directed towards me. It's most definitely directed at you. > You are a Java dev I presume? C#/C++. Though I've worked with java before amongst others. > As for app-level locking, I am talking about sacrificing performance, not safety. You are sacrificing both. Only idiots truly depend on app-level locking. > We just make sure that some piece of code runs exactly once. Amateur hour... > Since the need for this is very rare and the places are not performance critical, we can live with that. So no, we have no need for additional transactional guarantees on DB level. So it's a useless pointless trivial application...
      - annnnd 12y ago
        Incredible, I am being judged by someone on Internet... How will I survive this? </sarcasm> Another day, another idiot, I guess. (and yes, the term is definitely directed at you - if you still follow this throwaway account anyway)

by ttty 12y ago

annnnd 12y ago

>Use mongoose! We don't use node.js. Also, we have app-level schema, but enforcing should (IMHO) be done on DB level so as to avoid any chance of invalid data. Joins: easy, we specify which fields are connected (on app level), then fetching goes to connected collections and fetches data from there too. Not ideal, but it works. We made a similar solution for foreign keys. Transactions: no need for any further guarantees. Our system mostly works on a single record at a time in all critical components. If this is not possible, we have app-level locking to avoid conflicts. No issues or wishes here.

avasdvasdv 12y ago
> If this is not possible, we have app-level locking to avoid conflicts. app-level locking is a recipe for disaster if data matters and more than 1 process/user/client/etc can access your data. if the data doesn't matter then I guess you can do whatever you want. web "developers" have a bad reputation for a reason. so many amateurs amongst web developers...
- annnnd 12y ago
  I will assume the last part is just a generic statement and is not directed towards me. You are a Java dev I presume? As for app-level locking, I am talking about sacrificing performance, not safety. We just make sure that some piece of code runs exactly once. Since the need for this is very rare and the places are not performance critical, we can live with that. So no, we have no need for additional transactional guarantees on DB level.
  - avasdvasdv 12y ago
    > I will assume the last part is just a generic statement and is not directed towards me. It's most definitely directed at you. > You are a Java dev I presume? C#/C++. Though I've worked with java before amongst others. > As for app-level locking, I am talking about sacrificing performance, not safety. You are sacrificing both. Only idiots truly depend on app-level locking. > We just make sure that some piece of code runs exactly once. Amateur hour... > Since the need for this is very rare and the places are not performance critical, we can live with that. So no, we have no need for additional transactional guarantees on DB level. So it's a useless pointless trivial application...
    - annnnd 12y ago
      Incredible, I am being judged by someone on Internet... How will I survive this? </sarcasm> Another day, another idiot, I guess. (and yes, the term is definitely directed at you - if you still follow this throwaway account anyway)